I've been reading on the UnitOfWork class which sounds like exactly what i need to persist multiple stuff at one time. However, how can i use this over a webservice?

And second, i cant seem to figure out how to use this object with the businesslayer. If you used this in your UI to track changes and you persist them, wouldnt it be bypassing the business Manager classes? I am a little confused on how to use this object properly with a business manager layer....

1: UnitOfWork isn't supported in webservices.

2: Selfservicing always allows for bypassing the BL because you have everything to persist a UoW, adapter doesn't. You can't persist a UoW without a DataAccessAdapter, so you can't bypass BL in adapter with a UoW. You would have to write your BL to use the UoW and not your UI.

Answer wrote:

I've been reading on the UnitOfWork class which sounds like exactly what i need to persist multiple stuff at one time. However, how can i use this over a webservice?

And second, i cant seem to figure out how to use this object with the businesslayer. If you used this in your UI to track changes and you persist them, wouldnt it be bypassing the business Manager classes? I am a little confused on how to use this object properly with a business manager layer....

IMHO, the UnitOfWork is the right semantic but the wrong implementation for business layer method parameters. As a move towards Service Orientation and messages, the UnitOfWork represents the aggregation of data collected in the UI and is thus presented to the business/service layer as the set of data on which an operation should be performed:

Function UpdateUserData(userData as UnitOfWork2) as UpdateUserDataResults

So, you create service methods that take in a unit of work, parse the information contained therein, and either process the data locally or send the data off to other service methods depending on the need.

However, the fatal flaws in using UoW's for this purpose are a) the fact that the UoWs don't contain strongly typed members and thus can't be used to communicate the requirements of the service method in question; and b) they don't have a built-in mechanism to retrieve the data on the other side (outside of iterating the contained entities).

One solution is to create derived UnitsOfWork that contain strongly typed properties (Property UserEntity, Property ContactInfoToDelete); however, this would not preclude a caller from using the weakly typed methods (AddForSave, etc) which sort of undermines the purpose of creating strongly typed properties.

All of that notwithstanding, I think they're great; they're just limited in use. Oh, and yes, if you're concerned about proper encapsulation, use Adapter, not Self-servicing.

Jeff...

UnitOfWork objects contain data AND the actions to be taken on that data, as well as for example method calls to be called (through delegates). In general, it's a gathering object for work to be done.