Unit of Work with multiple Data Sources?

Question

It\'s possible (even probable) that I\'m just not fully grokking the concept of a \"unit of work.\" Basically, I see it as sort of a broad transaction used in an object-ori

Answer 1

I previously worked on a system that could accomplish this, and it is fairly straightforward. Since you project is in its early stages, perhaps this could be useful information for you. Unfortunately, I no longer have access to the code, but am still comfortable in describing how it worked.

What I had done was built my repositories using a generic repository pattern implementation. The base repository type would always be references by the services and UoW. For sake of discussion, we will call it BaseRepository. "T" would be restricted to IEntity implementations, which denoted a Domain Object. From the BaseRepository, I had created another set of base classes for compositing, such as SqlBaseRepository, XmlBaseRepository, etc.

The UoW only cares that something is of the type BaseRepository, which is where the core functionality would exist. Basic CUD (of CRUD) would be represented, providing the equivalents for Creates, Updates, and Deletes. What each of these would do would be to create a delegate and place it in a queue inside the UoW, also passing along information about what type of transaction it was going to be, and the appropriate data required to complete it. The UoW would start maintaining a list of what repositories were going to need to be involved in the transaction, but still did not care what type it was. Effictively, queueing up here is like enlisting in a transaction.

The BaseRepository defined an abstract method called something like .ApplyChange(). Once .Commit() was called on the UoW, it would create a TransactionScope() and start calling the delagates in the list, passing back the information to .ApplyChange(). The actual implementation of .ApplyChange() exists in the specific repository base, i.e. the SqlRepositoryBase, etc. and could be overridden by the implementation, as well.

Where it got tricky, for me at least, was rolling back. I only dealt with a single database, but sometimes had file-based changes that were made. I added a .RevertChange() method and started tracking the original state and modified states so that I could basically apply a reverse-delta to get back to where I was on the file stack.

I wish that I could be more specific on the implementation, but it has been over a year since I have seen the code now. I can tell you that the basis for the original code was borne from the book, .NET Domain-Driven Design with C#: Problem - Design - Solution, by Tim McCarthy. A large amount of my repository implementation was based on his examples, with a large majority of my customization coming in on the UoWs and their implementation.

I hope that helps, somewhat! :-)