Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

Tags:

.net

database

orm

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 DAL code generator and implement our business logic in .NET classes. There are several fundamental ways how we can express our ideas of business domain:

  • Implement business classes on .NET and let ORM generate appropriate database schema
  • Create database schema manually and generate .NET classes by code generator
  • Use some kind of visual designer, that can generate business classes and database structure or script

What do you prefer to write: "Create Table Persons ( ... )" or "public class Person { ... }"?
What are Pros and Cons of those ways?
Maybe there are some special situations where one way is better than another?
How to choose optimal way in a particular project?

I am quite familiar with "Code-First" (or "Model-First") way, but it seems most of ORMs are designed as code generators or mappers, that suppose that I will manually implement both database structure and business classes.

Answers based on expirience and examples of ORM's are especially welcome.

Edit: Note, the question is not "What should I do first when starting new project?", but "What should be manually declared / automatically generated, domain classes or database structure?"

like image 782
Alex Kofman Avatar asked May 28 '09 08:05

Alex Kofman


People also ask

Which is best code first or database first?

Versioning databases is hard, but with code first and code first migrations, it's much more effective. Because your database schema is fully based on your code models, by version controlling your source code you're helping to version your database.

Should I use code first?

If you're starting a new project, then it probably doesn't even matter. I would generally recommend starting with the technology you feel strongest in. For instance, if you're better at SQL than the coding language for the framework, then do database first, otherwise do code first.

Can we use code first with existing database?

To use code-first for an existing database, right click on your project in Visual Studio -> Add -> New Item.. Select ADO.NET Entity Data Model in the Add New Item dialog box and specify the model name (this will be a context class name) and click on Add. This will open the Entity Data Model wizard as shown below.

What is code first and database First in Entity Framework Core?

In code first approach we will first create entity classes with properties defined in it. Entity framework will create the database and tables based on the entity classes defined. So database is generated from the code. When the dot net code is run database will get created.


2 Answers

I think the appropriate approach to system analysis and design is to start by modeling your objects and the relations between them first. If you're creating a library system you should think of the phrases Book, Author, Publisher, ISBN as objects not as database tables or attributes. I believe this is the way it should be. That been said, let's admit that code generators save way a lot of time, and those require a relational database in order to generate the model and map it to the DB objects. I think this is the major reason why developers tend to start by the D.B. What could prove my point more is that code generators developers is trying hard to reverse the currently implemented operation (i.e. You provide a business model-objects and classes- and the generator creates the DB with the appropriate schema for this).

Edit:
Here's an example of domain-first generators (ADO.NET Entity Framework itself) Model First :

Visual Studio 2010 has to ability to generate a DDL and create a database to store the entity data model. The developer has complete control over the entire process being able to customize the DDL, or to select the database he desires, or fine tune the mapping process.

like image 97
Galilyou Avatar answered Sep 25 '22 19:09

Galilyou


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.

like image 26
Anton Gogolev Avatar answered Sep 25 '22 19:09

Anton Gogolev