I've been reading up on Entity Framework, in particular, EF 4.1 and following this link ( http://weblogs.asp.net/scottgu/archive/2010/07/16/code-first-development-with-entity-framework-4.aspx) and it's guide on Code First.

I find it neat but I was wondering, is Code First supposed to be just a solution for rapid development where you can just jump right in without much planning or is it actually intended to be used for large scale applications?

  • I think code-first approach is more suitable for mocking. So, it is more test friendly.
    – Gulshan
    Jun 22, 2011 at 15:21
  • 9
    Code-first is, at the very least, an excellent technology for working your DBA into an uncontrollable lather. Thus, it cannot be all bad.
    – 3Sphere
    Oct 25, 2011 at 20:35

7 Answers 7


I may have some detractors out there, but when I read some of those post from Hanselman and Gutherie, then read Julia Lerman's book on Entity Framework, I had a REALLY hard time with code first. In my many years of building applications, I've gone down many paths, both forced by process, and by choice, and have found that I have much more success when taking a data-centric view when building an application.

I'm talking about line of business applications here...this is when you have a business problem or process that needs to have a software solution behind it. You have data that needs managed in some way. It is better to know your data and how it relates to itself and how it is used within the business. Therefore, you model that data, and then create an application/solution around it. In my experience, if you start creating the application with the data as the afterthought, something eventually gets left out, and then you have some refactoring (in many cases - MAJOR refactoring).

Small applications may be an exception, but I will continue to use my data-centric approach.

  • 2
    This is may be because the approach is still a little foreign to me and I may change my mind later on, but even for small apps, I feel I would still be more comfortable building from the database first. It just seems to be the most logical point to start.
    – RoboShop
    Jun 22, 2011 at 13:49
  • 5
    Even when you base your database on CodeFirst, you are still using a data-centric approach. You are just modelling your data using .Net classes rather than strict database. If you can model your data in .net classes, which you would have to do anyway to know how to use the data, then I don't see how that's a major hurdle to let EF create the schema to support that data model.
    – KallDrexx
    Jun 22, 2011 at 15:41
  • 1
    I would also like to add that unless you're on EF 5.0+ and .NET 4.5+ choosing Code First will place performance limitations on your application due to not being able to generate CompiledQuery objects. I'm currently in the process of moving an application from CodeFirst to Database First because we're stuck with EF 4.3 Dec 6, 2012 at 22:44
  • A business problem implies business processes, which imply behaviour. Data is usually a side effect of that behaviour (unless you're talking about simple CRUD apps), so in my oppinion it's better to focus on modelling behaviour first, rather than on modelling a DB first. Mar 4, 2014 at 12:37

Code First is not suitable for large scale applications. Large scale apps development turnaround is very huge.

Typically life cycle of your business app is like,

  1. Version 1 is in production
  2. Version 2 is in beta
  3. Version 3 is in active development
  4. Version 4 is in planning.

And there are other Cross Application communication bridges, some scheduled tasks, some third party integration, web services for some different communicating devices such as mobile etc.

Eventually Code First uses Entity Model's ObjectContext, Older EF generating EDMX and using ObjectContext with EntityObject was really sufficient for everything. You could easily customize text template to generate code. Detect Changes method is slower with ObjectContext implementation, but instead of generating proxy, EF team could have easily improved Detect Changes speed instead of reinventing code first.

Automated Migration

Automated Migration sounds good in theory, but impossible in practice once you go live. It is only good for prototyping, developing some quick demos.

Code First Migration is not at all suitable in such system. Version 1 and Version 2 most likely talk to same database. Version 3 and Version 4 is usually staging and has different database.

Database First

Database First is practical approach, it is easy to compare and visualize and maintain SQL Scripts. DBAs can work with easily.

Text Templates

We created our own Text Templates to query and create EDMX and ObjectContext with little custom implementation that addresses performance issues. There are multiple applications with multiple versions communicating to same database without any problems.

To me, right clicking on .tt file and clicking "Run Custom Tool" is by far fastest and easiest step then writing classes, configuring and creating model.

  • Migrations are intended precisely for the scenario you describe.
    – Casey
    Oct 16, 2014 at 18:49
  • All migrations do (and they don't have to run automatically) is describe the series of database changes you want to make in code. If there's no conflict between the old model and the new one (or you don't need database changes at all) then there is no reason why you can't have two versions using the same database.
    – Casey
    Oct 16, 2014 at 18:51
  • 2
    @Casey That's a big IF, when considering the lifetime of an application :)
    – BVernon
    Aug 29, 2016 at 17:15

I do not see why CodeFirst can't be used in large enterprise projects. I will say that I use EF CodeFirst in several projects, one where the database is generated by my EF CodeFirst model and the 2nd where EF CodeFirst is mapped to an existing database.

From my experience, how effective CF is in a large project heavily depends on how abstracted your data layer is from your business layer.

For example, in one of my projects the business layer directly calls the database through linq. I use Linq to abstract away my database layer and use CodeFirst to map my POCOs into the database schema. In this case CodeFirst heavily makes the act of maintaining differences between DB conventions (relationship and table names) and my C# class names much simpler, and I can make database changes without having to heavily affect how my business layer interacts with the database.

However, in another project I have abstracted database access into a non-generic repository pattern, and my repository's Get* methods are solely responsible for running queries on the database, and they return real objects (not IQueryable<T>s). In this instance, the repository methods are converting DB entities into the POCO entities and in this case CodeFirst doesn't provides as much benefit to you as the CodeFirst POCOs are short lived and are quickly converted into business layer C# classes.

Ultimately, it really depends on how the team is structured and how comfortable the team (or seniors are) with the non-DBA engineers modifying database schemas, and how much schema changes are going to affect your code structure. With CodeFirst mapped to an existing database, it is trivial for me to remap a property to a new column name without having to do a global rename of that property name, which is especially a factor when you are talking about a name that makes more sense for a database field rather than a C# property. It is also trivial for me to add code support for new database fields without having to completely remodel my C# entities (one of the reasons I left Linq-to-sql to EF CodeFirst from an existing database).


Usually for large projects the database has already been created. Either because it's a legacy database or created by a competent dba for performance. The only benefit from CodeFirst is if you don't want to use EF's entities but instead POCOs.


It sounds to me like "Code First" is meant for using EF with more "agile" (don't harp too much on that term, I don't necessarily mean the methodology) and greenfield apps, where you don't have an existing data model or existing data; the kind of app that you could also use Django, or a PHP framework, or Rails for following those frameworks' guidelines which normally involve creating the data model as part of the code, instead of building an application around a data model which is the traditional Microsoft way of handling things.

So to answer the question I would say no; if you already have existing data and you are creating an application to handle it, Code First doesn't make as much sense. However, and I haven't used EF very much at all let alone Code First EF, it seems like it's a more loosely-coupled approach to code which is always beneficial. Assuming you can use Code First and then still point the class to an existing data model (instead of being forced to generate the model) the Code First approach could still help to write properly abstracted and testable code without all the usual "cruft" of using Entity Framework (i.e. the generated metaclasses).

  • I have a running application with 400+ and all was created using code first EF approach, I was able to use abstraction, inheritance much more easy than other modeling approaches ( Database first, model first), I advise to use the code first approach since it will give you the control over the code and easy to maintain, and you will not lose anything in term of performance and coding time.
    – Monah
    Apr 5, 2017 at 9:17

I would say in really large projects, code-first does not make sense.

In fact, when the project gets really large, you often have a strict separation of concerns. You can't have the same person writing C# code, doing database design, writing HTML/CSS and doing visual design in Photoshop. Instead, database design is done by a database administrator (or at least by a dedicated person who knows her job).

Since database is designed by a person who is familiar with the database, SQL and administration and database design tools, it would be strange to see this person using Entity Framework.

Moreover, I'm not sure if Entity Framework is powerful enough to design the database properly. What about indexes? Constraints? Views?

  • Hi, yes, that's what I thought. I think i guess it's neat, but I don't really see any advantage over doing it how I used to, which was to design the database first. I just wanted to make sure that it wasn't because there was something I didn't quite grasp.
    – RoboShop
    Jun 22, 2011 at 5:48
  • We added an extension library for our, very large, project that allows us to annotate indexes on the code-first entities - works great and was relatively easy to make.
    – casper
    Jan 12, 2012 at 16:05

Code first is viable for even large systems: Just examine the model after creation and remap using the fluent api until you reach a db model you like.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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