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

Posted by A. Karimi on Programmers See other posts from Programmers or by A. Karimi
Published on 2012-08-18T13:33:10Z Indexed on 2012/09/07 15:50 UTC
Read the original article Hit count: 327

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 |
|    |                               |      |
|    | ----------------------------> |      |

© Programmers or respective owner

Related posts about design-patterns

Related posts about architecture