Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Is there a performance difference between Model First and Code First in MS Entity Framework 4.1?

I'm starting a new development and I plan to use Code First in Entity Framework 4.1.

I have previously used Model First and found some performance issues around loading context, first calls to SaveChanges() and where Association Fix-up kicks in.

Has anyone compared performance of these two techniques - or, at the end of the day are they insignificant?

Thanks.

like image 574
Mark Chidlow Avatar asked Jul 16 '11 11:07

Mark Chidlow


People also ask

Which is better code first or database first in Entity Framework?

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.

What is difference between code first and model first approach?

Code first approach is used to fast development and developer has full controls on entities. Model First approach : We don't have an existing database and the Entity Framework offers a designer that can create a conceptual data model. It also uses an . edmx file to store the model and mapping information.

What is the advantage of code first approach in Entity Framework?

Code-First is mainly useful in Domain Driven Design. In the Code-First approach, you focus on the domain of your application and start creating classes for your domain entity rather than design your database first and then create the classes which match your database design.

Which approach is better in Entity Framework?

As in this diagram, if we already have domain classes, the Code First approach is best suited for our application. The same as if we have a database, Database First is a good option. If we don't have model classes and a database and require a visual entity designer tool then Model First is best suited.


1 Answers

I believe that there is no difference at all in performance. Code-First, Model-First, Database-First are modelling strategies at design time. For both Model-First and Database-First entity classes and a DbContext will be created with a T4 template. At runtime EF 4.1 just works with those classes and it doesn't matter where they come from - hand-written (Code-First) or autogenerated from the T4 template (Model-First, Database-First).

Also keep in mind that the benefit that Model-First gives you is rather limited in my opinion: You just have the possibility to create your model classes on a design surface in VS2010. But there are more drawbacks on the other side: The default T4 template isn't very fine granular in creating the code from the model. For instance: It doesn't put MaxLength attributes on the properties, it creates always navigation properties on both sides on a relationship (you often don't want and need both sides) and the overridden OnModelCreating method in DbContext just contains the single line throw new UnintentionalCodeFirstException(); which isn't particularly impressive. You can modify the template and the CSDL part of the EDMX file though to achieve more granularity when the model classes and the DbContext are generated (thanks to Ladislav for his comment below about this option).

In other words it is very likely that you have to tweak the generated code (adding attributes, removing unwished navigation properties, adding Fluent mapping code and so on) in order to get the finetuned model classes you want to work with. As soon as you have done this it becomes difficult to do any changes in the model designer because the DbContext generator will overwrite all your hand-made changes in the code.

In my opinion Model-First with EF 4.1 is only useful if you already have a model designed in the designer surface for instance from an older EF 4.0 project and you want to migrate your project to EF 4.1 In this case the DbContext generator might be useful to create initial code for you. From that point I would proceed with working in the code alone which means: Working with Code-First. If you start with a new project I would prefer Code-First from the beginning. Even if you really want or need this visual representation of the model in the designer surface also in Code-First you can simply create an EDMX file from your DbContext and open it in VS2010 to show your model classes and their relationships in the designer:

using (var context = new MyDbContext())
{
    using (var writer = new XmlTextWriter(@"c:\MyModel.edmx", Encoding.Default))
    {
        EdmxWriter.WriteEdmx(context, writer);
    }
}

Edit

There is actually one point where EF 4.1 recogizes the difference whether a model comes from Model-First (i.e. an EDMX model file and designer surface) or if it is a pure Code-First model - and that is the connection string. If you create a model from Model-First you get a connection string which contains references to the model metadata files, like so:

<add name="MyConnectionString" 
     connectionString="metadata=res://*/Model.csdl|res://*/Model.ssdl
         |res://*/Model.msl;provider=System.Data.SqlClient;
         provider connection string=&quot;data source=.\sqlexpress;
         initial catalog=MyDb;integrated security=True;
         multipleactiveresultsets=True;App=EntityFramework&quot;"
     providerName="System.Data.EntityClient" />

Whereas for Code-First simply a "normal" connection string without metadata references is used:

<add name="MyConnectionString" 
     connectionString="Server=.\SQLEXPRESS;Database=MyDb;Trusted_Connection=Yes;"
     providerName="System.Data.SqlClient" />

Now you can use the second simple connection string without problems also for a model which is created via Model-First. But the code snippet above (creating an EDMX from DbContext) throws an exception with the first connection string telling that WriteEdmx can only be used with Code-First but not Model-First or Database-First. So obviously the DbContext processes or stores somehow the metadata information from the connection string.

How to interprete this? Does it mean that it actually uses the data in the EDMX file specified in the connection string when the model is built in memory? In this case there could theoretically be a performance difference between Code-First and Model-First (at least at model-build-time). But I don't think that the metadata are actually processed. But the mentioned exception is somewhat weird. Why does EF 4.1 prevent me to create an EDMX model file when my model comes from Model-First? Perhaps just to avoid possible confusion and mess with two EDMX files? I don't know.

like image 53
Slauma Avatar answered Oct 13 '22 22:10

Slauma