问题
I'm using a the Repository pattern as part of a C#4 and MVC3 project and I just want to make sure I'm not doing something bad; either that or it's just my architectural pedantry getting a bit carried away with itself and I just need a figurative slap round the face :)
For a particular model type I need to be able to do the following two operations:
- Create a new instance in the repository so long as another doesn't exist with a certain state value
- Update the state value of an instance in the repository only if it's not already at that state
In both cases it is crucial that the operations be atomic as they are used to make crucial decisions.
Since a database is going to be the initial endpoint for the repository, this can be implemented with transactions in a couple of stored procedures. However it means that instead of Get/Insert/Update methods on my Repository interface, I need Get_Or_Insert and Compare_And_Update semantics so that the application can expect the atomicity from the Repository rather than enforcing it itself.
It's not really possible for me to push the transaction back to the calling code, in particular because I can't guarantee the immediate repository will be a DB, but could be a web service (or other things); and frankly mediating transactions across web services, whilst I know it's possible, is just a bit too heavy (especially in terms of implementation) for such a simple operation in my book!
So, can I happily add these special case operations to the repository, or am I following the pattern wrong?
回答1:
for what it's worth, allow me to offer a friendly "figurative slap round the face" :)
remember that patterns exist to serve you, and not the other way round. If you have a justifyable need to 'bend' the DP a little- I believe it's OK.
Especially in light of the fact that you don't currently have any better idea (nor do I, by the way).
来源：https://stackoverflow.com/questions/5472566/atomic-insert-or-get-and-compare-and-update-a-repository-violation