IDataContext exposure

Apr 17, 2013 at 7:45 PM
Edited Apr 18, 2013 at 6:32 AM
Hi,

First let me say that this is a magnificent pattern, I really like it. I have read your posts about it and watched your presentation. I am trying to understand it as best as I can, I think it is really good. I am going to do a presentation in my company on it and we are probably going to adopt it in some degree.

I have a question though, I hope you are still monitoring this project :)

When implementing an Onion architecture in ASP.NET MVC, it is my understanding that we should/could expose the IDataContext interface, which can be injected and referred to in the UI. I think that you intentionally have not exposed a Save capability, in that IDataContext interface.

The IDataContext should be exposed as readonly (i.e. without SaveChanges method in it), for querying purposes, while the C_UD (R is omitted here) methods should be exposed as Domain Services. Right or wrong?

If the above statement is correct, then ве would end up with something like:

DomainService.cs:
private IDataContext context;

public DomainService(IDataContext context) {
this.context = context;
}

public void RemoveProductFromInventory(Product p) {
context.Products.Remove(p);
context.Save();
}

BUT... how do I force the implementation of IDataContext to provide a Save method, hide the Save method of the IDataContext from the interface and in the same time force the implementation of IDataContext to also hide the Save method? Because if we provide Save method to the UI, there is no guarantee that the developers won't abuse the data storage and implement their own business logic.



Thank you so much in advance!