Question

My business logic and core entities are tightly coupled.

• An object, for example, called Session is a database entity but in literal terms of the word is a real life Session during which events are recorded.
• This Session object also has [NotMapped] objects and handles to unmanaged resources.
• The Session object also implements IDisposable.
• A good chunk of entities in my project have the above characteristics.

This sounds like disaster down the line. The question is what approach to take here.

I am expecting answers to point to design patterns or architecture but please do include a very short code example to illustrate your point rather than just the name of the proposed solution.

What I have thought of so far is to derive from each entity as a business object and use code generation to convert from one type to the other. Since this is a client/server application, I want to be able to use the entity relationship set as-is in my desktop app, albeit a derived one.

Not sure how to achieve this in a sustainable way.

Answer 1

This is not about design patter but about ownership of the disposable entities. Who owns the entity? The owner is responsible for disposal. That is something defined directly by your code / design.

EF context itself is disposable – you can override its Dispose operation and force it to dispose all attached entities but that is most probably something you don’t want to do because context is most probably not the owner of the entity. The code requesting entities from context or requesting persistence of entities should be considered as owner responsible for disposal.