Reputation: 1775
I have heard that there are downsides to POCO with Entity Framework, but I am not 100% sure what they are. I heard that there are issues with change tracking. What are the major downsides and what are the workarounds? I am looking into using POCO Entities in an upcoming project and want to be fully prepared.
Thanks!
Upvotes: 1
Views: 551
Reputation: 364319
Downfalls depends on type of application you are going to write. POCOs are great from architecture perspective because they do not introduce dependency on Entity framework. The problems with change tracking can be divided into two separate blocks:
Detached entities are not only problem of POCOs. It is a global problem in EF and perhaps in the whole ORM concept (but other APIs have probably better tools for dealing with this problem). The point is that ORM is responsible for persisting changes made to entities. To do this it offers some change tracking mechanisms but these change tracking mechanisms work only if ORM knows the entity. Once you detach an entity (in case of EF call Detach
or dispose ObjectContext
or create entity without loading it from database - common in web applications and web services) EF doesn't know about changes and once you want to save the entity you must tell EF what has changed. This is easy to do in case of single entity but it is pretty big challenge in case of whole object graph. This can be partially solved by STEs but I don't think that STEs are good solution for the problem - they are useful only in some scenarios.
Performance problems are related to change tracking as well. There are several reports showing that if EF wants to track changes in entities it requires very long time to initialize change tracking (when entity is loaded from database or when it is attached to the context). This problem is important only if you plan to work with large data sets.
There is still a lot of successful projects using POCOs and most of the projects probably never meet any of these issues.
Upvotes: 4