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.

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.

Yes, there are performance differences between Model First (EF 4.0) and Code First (EF 4.1 - 4.3.1):

• You cannot pre-generate internal query views. This means that every time EF tries to run its first query (per app domain), it will need to perform an expensive operation to generate those views, depending on your model complexity. This usually affects application startup performance and can make debugging quite annoying.

• You cannot use compiled queries. This can seriously affect queries that are used often, especially complex queries. It can become a serious bottleneck and a CPU hog. Only EF 5.0 (that will be included with .NET 4.5) fixes this issue by automatically compiling all queries, including Code First queries.

According to this benshmark yes. It says also that EF Model First is always faster than EF Code First.