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 patternKeep 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 layerAdd 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 ||    |                               |      ||    | ----------------------------> |      |
How to use the unit of work and repository patterns in a service oriented enviroment
design patterns;architecture;soa;repository;unit of work
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.