Should I design the application or model (database) first? [closed]

Answer 1

When you're building the whole application yourself, I would start with the user. What does the user want? What information do they need? That should drive the design of the application and model, not the other way round. When the model is designed first, there is a temptation to expose the user to it directly, which will rarely make sense.

Answer 2

For me it depends previous experience with the problem domain.

If I have done this sort of app before, I am more likely to take the time to clarify the data model first and then start building code on top of that.

On a first-time project I am more likely to just jump in with coding, whipping up dummy data as needed and learning about hidden dimensions of the problem domain as I go. Not uncommonly there are data categories that would have been difficult to anticipate. When I discover these, I revise the data model and continue on. Often this approach begins with coding up a script to build the database and populate it. That way, on subsequent iterations, I just modify the db-build script, run it, and I'm back in business.

Answer 3

FWIW, one of the best remembered parts of Brooks's The Mythical Man Month is this:

Show me your flow charts and conceal your tables and I shall continue to be mystified, show me your tables and I won't usually need your flow charts; they'll be obvious.

Answer 4

First of all, your database is not your Model, it is just the mechanism you use to persist your model. Your model is a set of business objects the encapsulate the state and logic used by the business, and may be used by other applications.

I have found that most clients don't understand tables, columns, but do understand process and workflow. Therefore, I work with the client to mock up the UI and the page flow for the tasks that need to be addressed in the solution. From this, I create the business objects to hold the required data for the UI.

The controllers handle the page logic and page flow. I mock up a data repository to handle some sample data. This allow the client and I to iterate the UI and flow until we are satisfied. Usually, we discover better ways of doing things, and the some activities they thought important, add no value.

Now is the time I work on the database and the data access logic. Waiting until this point reduces the need to rework database schema, stored procedures, and DAL code.

This usually results in less code, a robust application, and a happy client. The triple crown.

Also, Unit Test everything. You will be making changes, and a good unit test set makes sure that you don't break other parts of your application when you make the changes.

Answer 5

You don't want your object model to be constrained by a database design. The database should be a persistence implementation of your object model, which is the one that rules. You can wrap your application around your object model, and also derive the persistence model.

Answer 6

You could start by designing the interface between the application and model and writing unit tests for how the interface should behave. I usually take the more agile approach and do only a little upfront design before I jump into the code (see: Pragmatic Programmers From Journeyman to Master Tracer Bullets concept).