3

I'm currently working on designing a small web application (MVC5) and I'm to the point of designing my database. I have the schema I want worked out and I am quite proficient in SQL Server. (I have my SQL 2012 MCSA.) I'm going to be using entity framework 6 as my ORM. I've been quite interested in the code-first approach because I'm not a big fan of designers and I like to be able to see and work with the code myself.

Because my SQL skills are quite strong I am inclined to create the schema myself and write my own CREATE TABLE queries, etc. I feel like that gives me a lot more control over constraint and index creation.

But I haven't really worked much with entity framework in the past so there may be some benefits to this that I'm missing. I know you can do code-first against an existing database in EF6 anyway, so that would be another option.

I've tried googling around a bit and reading MSDN but most of the benefits seems to be that you don't need to worry about the SQL. Since that isn't a concern of mine I'm failing to see the benefit of allowing entity framework to create my schema.

Are there any benefits to allowing entity framework to create my database that I'm missing?

  • 2
    If you know SQL (and it certainly sounds like you do), I guarantee you'll build something better by hand. Performance is certainly my biggest concern; I don't imagine EF6 does much to make sure tables are properly organized/indexed based on their usage characteristics. – mgw854 Sep 5 '14 at 3:03
  • Consider this approach: Prototype in code and let the ORM lay out the bulk of the tables. Then extract table creation SQL and "fix" it by adding indices, constraints and what not. – Petter Nordlander Sep 5 '14 at 4:09
  • @mgw854: even for code-first, you have full control over indexing (see blog.oneunicorn.com/2014/02/15/…), and if that's not enough, you can add indexes manually after DB creation. – Doc Brown Sep 5 '14 at 4:12
  • 2
    related: stackoverflow.com/questions/5446316/… – Doc Brown Sep 5 '14 at 4:31
4

The biggest benefit in my opinion is that it allows you to focus on designing the model, not the database used to store it.

This makes things like separation of concerns etc. easier as your mental approach is already doing that by seeing entities as simple classes, not database tables.

Of course, you can always use Fluent API and data annotations to tweak the generated database scheme where needed, and once things settle down you can switch on migrations and use that to generate the comfort blanket that is SQL scripts (in a good way!) for deployment and schema management going forward.

  • 1
    That is a good point about being able to focus on the design of the model rather than the specifics of the database design. I do like the Fluent API. I also like the idea from this blog post about how using code first and migrations allows you to easily version control your database design: itworld.com/development/405005/… – Mike D. Sep 7 '14 at 23:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.