Service and Repository pattern and Separation of Concerns

Question

I'm using a service/repository layer design pattern on top of Entity Framework. Everything was fine until I wanted a query to return an amalgamation of data about two distinct entities.

The example is I have the two entities Document and ShoppingBasketItem. So I now have two services a DocumentService and a ShoppingBasketService. At first I just listed out the documents based on a users search. But later I wanted to highlight the documents that where already in the users shopping basket. So the document service now needs to know about the concept of shopping baskets.

Really I wanted the Document service to have nothing to do with shopping baskets, a clear separation of concerns.

So my question is, is this a good approach? Or should I possibly create a new service a DocumentBasketService that handles queries regarding information of documents and shopping baskets?

Answer 1

So my question is, is this a good approach?

It depends.

I have some reserves with the approach of defining services this way. You would like to achieve SoC which is a smart thing to do, but I think that we have to work on the definition of concern. Is a concern really a domain object in this case? Judging by the issues you are facing, it doesn't look like it.

I have seen this implemented times and times again: after all, it may seem logical to define a DocumentService working with a DocumentRepository. In my experience they end up forwarding some/most of the calls to the repository directly and having a huge service contract, because eventually all that has to do with Documents will end up in the DocumentService.

If you are doing service orientation, the solution I normally adopt is to make my services speak "business" and not domain, making them implement business cases and not relegating them to wrapping a repository. Then you can achieve SoC in your services, and your concerns are business concerns: the definition of these concerns is entirely dependent on your business cases though, which means that I can't help you there. OTOH, if you really need domain services this piece of advice is completely useless; as I said, it depends on your needs.

So the point that is universally valid is: reconsider what concerns you are trying to separate and what you want to achieve with that.

Answer 2

Hmm I may have come up with an answer that keeps the clear separation of concerns.

I have added a new method to the Document Service which accepts as a parameter a list of document IDs, these ids are the documents that already exist in the users shopping basket. The service can then just highlight the documents, e.g. set a property on the document to indicate that it's already in the users shopping basket.

This way the document service is not querying shopping baskets and really knows nothing about them.

So to sum up my controller action calls into the shopping basket service and gets a list of id's already in the users shopping basket. It then calls the get documents method on the documents service passing the list of ids.