Entity Framework 4 and Poco and Linq2Sql performance_问答_开发者

I`m thinking of using POCO instead of automatically generating the entities, cause i don't want any dependency on the framework

i was wondering if that will have any performance hit, I`m not sure if having to dynamically proxy my entities at run-time will affect performance ,

also i wonder if it gonna be faster if i just let EF4 generate the model for me.

I care about performance a lot in my current project and I have read many times about how L2S is slightly faster than EF2 but I'm not sure about EF4, so now I wonder if I will have performance issues by using EF4 instead of Linq2SQL.

I really wanna use POCO; that is why I prefe开发者_StackOverflowr EF4 but then again I don't wanna have performance issues.

EF4 and Ling2SQL are the only options for me because I can't use native ADO.net or any other ORM, so can you please share your experience about EF4 and Linq2SQL from a performance perspective?

thanks in advance.

If you're really concerned about performance, take a look at Dapper.NET. This section of their main page has a pretty decent comparison of the various OR frameworks out there, including LINQ to SQL and Entity Framework.

In general, POCO is your fastest option. Dapper would help you with that.

FYI: Dapper is used by StackOverflow, and StackOverflow is amazingly peformant for the amount of traffic it generates.

Recently, ADO.NET team releases the EF Power Tools to support code first development, which automatically generates POCOs from you model/database(mssql only), and could completely separate POCOs from other meta classes to give structure information of database tables.

At ADO.NET team blog, using EF Proxies is mentioned as following

When creating instances of POCO entity types, the Entity Framework often creates instances of a dynamically generated derived type that acts as a proxy for the entity. This proxy overrides some virtual properties of the entity to insert hooks for performing actions automatically when the property is accessed.

Sometimes disabling proxy creation is useful to prevent the Entity Framework from creating proxy instances. For example, serializing non-proxy instances is considerably easier than serializing proxy instances. Proxy creation can be turned off by clearing the ProxyCreationEnabled flag.

Of course, creating proxy would be not good at performance, but as mentioned above, it just overrides some virtual properties for loading relative properties so that I think creating proxy objects instead of POCOs is not a problem.

I haven't noticed a tremendous difference between POCO and model/database first in terms of performance. I have noticed that EF is slower than Linq2Sql, Massive, PetaPoco, Ado.Net and possibly nHibernate.

Stacker, not sure about performances exactly yet but I would not really worry about that.

if you want to keep your entities clean ( as I do ), even if generated by the EF, you could use the power of partial classes of C# and have another file ( in the same project, your data layer ) where you have the entity definition again as partial and where you specify that such entity implements your base interface.

This way in another assembly, called like CORE or Common or better Core.Interfaces... you have all interfaces defined and in the upper layers of the app stack ( Business Logic, UI, services etc etc ) you always and only program against those interfaces instead of the DAL namespaced entities...

this gives you a lot of power because once you refresh the model from the db and so on, if the new generated entities break the defined and common interfaces you get immediately a compile time error. Notice that you don't have to change anything in the auto generated files for the entities of EF since you use partial classes definitions.

Hope this helps...