Performance Considerations for Entity Framework Applications
There are lots of good articles, comparisons and tests of raw Ado.Net SQLDataReader, Linq for SQL, and Entity Framework.
From the performance comparison results, it appears that the Entity Framework was intended as a middle-layer business object repository. The performance sucks if the queries are created and executed ad-hoc, whereas it gets much better during repeated queries. The business object should be instantiated and kept memory in a separate layer/service.
For better performance and scaling applications, Linq for SQL or just plain old datasets and stored procedures are still a faster option. But, that comes at a loss of a proper business layer.
There are lots of good articles, comparisons and tests of raw Ado.Net SQLDataReader, Linq for SQL, and Entity Framework.
From the performance comparison results, it appears that the Entity Framework was intended as a middle-layer business object repository. The performance sucks if the queries are created and executed ad-hoc, whereas it gets much better during repeated queries. The business object should be instantiated and kept memory in a separate layer/service.
For better performance and scaling applications, Linq for SQL or just plain old datasets and stored procedures are still a faster option. But, that comes at a loss of a proper business layer.
No comments:
Post a Comment