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