Welcome to my shared enviroment for knowledge and experience. This place is intended to let people learn from what others have to give.
"If we had enough knowledge and experience, then any problem would be resolved in just 10 minutes... theory of 10 minutes by Alexandro Velarde :-)"
Do you concur??

Let's start by changing the file arrangements in our solution. Let's add two class library projects: one to keep the database scripts and batch file and another named EFApplicationWithPOCO for the POCO Classes and Context.

Add a new ADO.NET Entity Data Model by using the Update Model From Database wizard to generate the model.

Empty the Custom Tool property of the Edmx file. This will remove the EF4DomainModelForPOCO.Designer.cs auto generated file and it won't generated again.

Here are the results. Look at the huge difference between POCO and auto generated entities.

SummaryI think there should be more performance test to be done, but thisone gives you a good idea on where to focus.

What's next?

In the next post, I can enhance the performance test with much more complex cases to measure the POCO performance for tracking. After we can see how to write templates to auto generate POCO classes or any good idea you can come up with... Let me know!.

10 comments:

Alexandro, great info. Coming from Subsonic (2.x) I have been lazy using partial classes as business layer objects but now when moving over to EF I wanna do it the right way. You gave me another reason for using POCOs

Hi Pedro, thank you for your comment. Yes, I did and the results are the same. Plain Old CRL Objects don't inherit from EntityObject and are not aware of persistence framework. I could have done the same test without any database access by just iterating through objects.

I think the poco function are not virtual so you don't have a proxy that means it is like a detached object. I've seen in other places that tracked object (the entity object or proxies) have a high performance cost in some scenarios...With a proxy the result probably will be closer to the entity framework object

Have you considered the possibility that the results are a bit skewed due to caching? I don't see anywhere that you cleared the database cache between the test runs so there is the possibility of that benefit to the second (POCO) test run.

You could either clear the cache by running this between the test:DBCC FREEPROCCACHEGODBCC DROPCLEANBUFFERSGO

Pages

About Me

A fellow amateur software developer very interested in technology, software, design patterns, unit testing and any great innovative technology out there that works and makes life easier to others. I like automating processes, developing software, sharing knowledge, learning, investigating and trying new tools to keep improving knowledge.