Is CodeFirst intended for large scale applications?

Question

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?

Answer 1

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.

Answer 2

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).

Answer 3

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).

Answer 4

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.

Answer 5

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?

Answer 6

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.