Question

Take the scenario where you have the following application:

• An MVC 4 Web App
• The application talks to an existing database via Entity Framework 5
  (with no plans to change to another ORM or database platform).
• The application talks to an external SOAP Web Service (the webservice
  may change to WCF).

Would you:

1. Create a generic repository for all the EF entities (e.g.
   MyDBRepository), and a repository for the SOAP Web Services calls
   (E.g. MyWSRepository). Then create a service class that contains the
   business logic uses the two repositories to access data and
   implements CRUD methods for all the controller’s needs
   (MyApplicationService). Then have the repositories injected into
   the service class, and finally the service class injected into the
   MVC controller.

2. Or would you have one service class that handles the db queries and
   business logic using the EF generated DBContext and the generated
   table entities (e.g. MyDBService), and another service class that
   handles the business logic and SOAP web service calls (e.g.
   MySOAPWebService). Then have both services injected into the MVC
   Controllers.

3. Or something else.

In the past I’ve worked with option 1. But I’m wondering if that is just adding unnecessary layers of abstraction. If the Entity Framework generates a DBContext, having a service class that uses the DBContext entities directly seems to be less complex.

Having read through several articles and other questions in StackOverflow, it seems like there is a grey line differentiating the Service Locator pattern and Repository Pattern.

Which structure would you use?

Answer 1

I recommend a repository or DAO for each aggregate. make these classes receive the dbContext on the constructor (or unit of work if you prefer).

Then make your service implement the business logic and use the DAOs. The service is responsible for instantiating the DBContext (and a transaction if you require one). Services then call different DAOs with the same context.

For a more strong decoupling I strongly recommend that you make impossible for the service layer to touch the DBContext. Force yourself to go through the DAOs every time.

The service layer should also deal with exceptions. In my applications the service layer only throws 2 types of exception: user and system. On the controllers i use them to tell apart a recoverable error or something else. ( that’s why you sometimes see specif errors like “invalid order number” or something else like “An error occurred in the system, try again later”)

Btw, never forget to work with disconnected entities. when you call your repositories for add/update always assume the POCO’s are disconnected and work with them accordingly.