Are the context of an entity framework application is owned by the domain or data access layer?

Are the context of an entity framework application (DbContext that contains mapping) is owned by th开发者_运维技巧e domain or data access layer ?

Thanks.

---

in your scenario the context should only be used within the data access layer and then the results passed to your domain - something like automapper will translate context entities into domain objects

---

My $0.02 is that it should be "owned" (Disposed) by your DI container. It should be used by your unit of work implementation.

---

It completely depends on your application. Sometimes having a seperate domain layer with its own domain objects makes sense. Sometimes it doesn't.

Indeed, for most applications, I would say that the EF entities are perfectly suited to be your domain objects and there is no harm in referencing the context directly from your "domain" layer. Indeed, the EF is designed with that in mind. Creating an entirely sepearte set of domain objects into which your EF entities are mapped by some middle man layer needs to be justified.

That's not to say that having a distinct domain layer is never appropriate. Sometimes, for instance when you're dealing with cross-process/application boundry issues such as when you're exposing your entities via WCF, it makes total sense to create new domain objects (which in this case may essentially just be your DataContract classes) into which your entity's data is populated.

But these instances really are few and far between. If you find yourself doing this often, you're over-architecting your application and you're falling victim to the dogma of "pure" design paradigms.