Service Layer/Repository Pattern

Question

I am building an MVC app using the Service Layer/Repository/Unit of Work pattern with EF4.

I am a bit confused on the logic. I know the point is to decouple the system, but I am a little confused.

So the MVC Controllers call on the Services to fill the View Models. So is it safe to say the MVC App is coupled to the Service Layer?

Then the Service Layer calls on the Repository to get and persist objects. Is then safe to say the Service Layer is dependent to the Repository?

The Repository the utilizes EF4 to get and persist data to SQL server, so I would assume the Repository depends on EF4 which in turn depends on SQL Server.

Where does the unit of work all fit in.

Any examples please? Thanks!!

Answer 1

I started with hiding Unit of work somewhere in lower layer but it is wrong way to do that. After some experience my opinion is:

• In case of monolitic application UnitOfWork should be accessible by Controller and lower layers.
• In case of distributed application (UI and BL are on different servers) UnitOfWork should be accessible by business layer facade (service layer for remote calls) and lower layers.

The reason is that mentioned layers define what is the "business transaction" = what is current unit of work. Only this layer knows when it wants to commit changes to data store. Doing it this way allows service composition (code reuse). I discussed similar question here and here.