How to use the unit of work and repository patterns in a service oriented enviroment

Question

I've created an application framework using the unit of work and repository patterns for it's data layer. Data consumer layers such as presentation depend on the data layer design. For example a CRUD abstract form has a dependency to a repository (IRepository).

This architecture works like a charm in client/server environments (Ex. a WPF application and a SQL Server). But I'm looking for a good pattern to change or reuse this architecture for a service oriented environment.

Of course I have some ideas:

---

Idea 1: The "Adapter" design pattern

Keep the current architecture and create a new unit of work and repository implementation which can work with a service instead of the ORM. Data layer consumers are loosely coupled to the data layer so it's possible but the problem is about the unit of work; I have to create a context which tracks the objects state at the client side and sends the changes to the server side on calling the "Commit" (Something that I think the RIA has done for Silverlight). Here the diagram:

----------- CLIENT----------- | ------------------ SERVER ----------------------

[ UI ] -> [ UoW/Repository ] ---> [ Web Services ] -> [ UoW/Repository ] -> [DB]

---

Idea 2: Add another layer

Add another layer (let say "local services" or "data provider"), then put it between the data layer (unit of work and repository) and the data consumer layers (like UI). Then I have to rewrite the consumer classes (CRUD and other classes which are dependent to IRepository) to depend on another interface.

And the diagram:

----------------- CLIENT ------------------ | ------------------- SERVER ---------------------

[ UI ] -> [ Local Services/Data Provider ] ---> [ Web Services ] -> [ UoW/Repository ] -> [DB]

---

Please note that I have the local services layer on the current architecture but it doesn't expose the data layer functionality. In another word the UI layer can communicate with both of the data and local services layers whereas the local services layer also uses the data layer.

|    |      |                 |      |      |
|    | ---> |  Local Services | ---> |      |
| UI |      |                 |      | Data |
|    |                               |      |
|    | ----------------------------> |      |

Answer 1

You can add idea 1 on top of idea 2. So I would start with idea 2.

I would avoid having lengthy conversation stored locally at the client end. It will result in synchronization complexity and the client may end up being very chatty (and thus slow).

Try looking at your web service as a facade. Try sticking to a single call - complete operation pattern.

Ask yourself why do I need a client side unit of work.

Answer 2

If you stop worrying about your data and start thinking about your domain model it will become much more clear. I now see you are stuck with unit of work, repositories, data operations, layers and adapters but you forget about your business.

What I would suggest to do is to have proper rich domain model designed and have a service layer that will play together with your domain to do work for your business. When this is done. All the UI would need to do is to send this service layer DTOs with input models and get DTOs back with view models.

Answer 3

I'd argue that your second approach is on track. To me, exposing the repositories/uow directly to the client is brittle. Your client becomes dependent on the mechanics of the domain layer (and this gets exacerbated as you add different clients to the server tier).

There is another pattern, the Application Service Layer that provides a shell around your domain model and acts as an intermediary between the client and the domain. It allows you to create operations that a custom-fit for the client, and for the details of the domain to still be fluid without impacting the client.