Code-First or Database-First, how to choose?

Question

Let us suppose we are going to start new project - application that contains some business logic, user interface on ASP.NET, WPF or both of them. We\'d like to use ORM or DA

Answer 1

Why not interface-first?

Too many apps start with a program-first mentality. That's a bad idea. Programming is the heaviest component of building an app, meaning it's the most expensive and hardest to change. Instead, start by designing first.

Design is relatively light. A paper sketch is cheap and easy to change. html designs are still relatively simple to modify (or throw out). That's not true of programming. Designing first keeps you flexible. Programming first fences you in and sets you up for additional costs.

This is from Chapter 9 of Getting Real by 37signals.

Answer 2

Analysis of requirements first, and then some documentation of those needs and an overview of the data aspects of this?

Then you know what data you'll be capturing and how it relates to other data, and can design a database schema or data structure to match it (as logical objects/tables of related content, not "tab1_data", "tab2_data" matching the data capture process which could change, but you know that!). You could even design a .xsd first and generate code and a database schema from that. It's all fun and games these days, depending on your skillset.

As the database schema in my mind stores the data, and that is the really important thing for a business to have, I would design that first - multiple tools may access it in time, maybe the original system would be replaced down the line (e.g., migration to newer tools/languages/interfaces). If you know nothing about database theory, then maybe that's not your best option but I would still get any generated schema verified by someone else.

Answer 3

“Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious.”

— Fred Brooks in “The Mythical Man-Month”

Answer 4

In most cases it won't matter much. It is more up to personal preference and skill than anything else. Most apps are not going to suffer much either way, use whatever your team is comfortable with. Where the choice really matters it should be obvious which approach to go for.

That said, my personal opinion is that "database first" is generally the safer choice. If the data is in any way important, especially if it is important outside the scope of your particular app, you want to have full control over how it is stored.

"Code first" (implied: leaving the database in the hands of some automatic tool) is in my mind really a shortcut, one you should use when (and only when) you know for sure you can get away with it.

Answer 5

Personally I like control over creating RDBMS objects. When I use the EF code first, it actually created more work for basic things such as table relations etc. which most decent code generators does for you out of the box ( I know thats the idea ... more control on your Models!). Also the Idea that EFCF will generate the db as I am hoping for is a bit scary. (traditionally Code evolves more easily then RDMBS!)

For a system which required constant evolving (for e.g. SaaS), and usually a large Enterprise Level system with 500 + tables etc, its can be less attrative proposition. On the other hand if you have a proper SQL Server 2008 database project with all the tables,SP,Triggers, Indexes scripted and you can deploy them from the Visual Studio it much more managble. You now have freedom of using any codegen you want for your tables (even build your own)

You are not tied to the on Framework (EFCF) you can then use different ORMs (NHibernet for e.g.) depending upon your 'mini' project requirement in your large system.