I'm working on architecting a somewhat enterprise-level solution and have a question about how to best handle the persistence details.
My overall setup is that there's a core set of business logic/objects, as well as a number of isolated components that rely on the core logic, but never on other components. Sitting on top of this component/core business logic layer is application logic and presentation stuff. Underneath these two layers is infrastructure and persistence.
note: currently I'm working on the Core specifically, haven't gotten into Components yet
My Current Persistence Implementation:
Currently (and incorrectly, I suspect), my Core project has a reference to the Persistence project, and a Core model (Orders, let's say) has an IOrderRepository field. When the Order is instantiated, I can pull up the info, I can save it, etc.
My Current Concern:
1) My core domain objects are not following SRP because they essentially have persistence details attached to them (despite those details being interface details rather than implementation details, it's still there).
2) Upon reading a good article on managing EF's DbContext (which can be considered in a more generic context form than EF specifically) (ref: http://mehdi.me/ambient-dbcontext-in-ef6/) - I've realized that it makes little sense to loading a persistence context when a domain object is loaded, because it's not at all representative to the context in which the objects are used (e.g., the objects could be loaded under any number of contexts) (note also that I haven't forgotten about Aggregates, but not included here for simplicity because the end result is the same, I think).
What Seems Better:
It "feels" better to me that the persistence context (and thus the DbContext and thus the repositories) should be handled under the general context of any specific business task rather than simply on a business object, which, in itself, has no true context despite the fact they do encapsulate various behaviors (is this statement correct??).
Considering that a persistence context/dbContext is can essentially be considered a transaction, it thus seems more correct in an architecture sense that such persistence context should in fact be included where these driving actions begin, as this is the context in which they essentially operate.
What I Can't Seem to Grasp:
How do I set this up so the persistence context is closer to the context in which it's used (which feels right, but correct me if I'm wrong), while at the same time fully separating it from the domain objects so those latter maintain their required SRP (e.g., so I don't have Save() and Load() methods on the domain objects, no matter how well abstracted away they are)?
I appreciate any input on how to best keep this from turning into a tangled-up mess. Thanks