So yes what you said.

@JustinEtheredge

The solution you provided, doesn’t seem like a very good solution to me.
By doing this, the RequestProcessor (the one who resolves the RequestHandlers and calls their Handle method) would have to know which types have a Handle method with a UnitOfWork and which don’t, probably resulting in an if-cast and at least 2 different ways to call a RequestHandler. If for some reason another type of RequestHandler is introduced it would result in yet another if-cast-callTheSpecificHandleMethod.
Or am I missing something and how would the RequestProcessor look like then?

Who really sounds like a drone here? I just stated my personal preference, which i think i’m allowed to do

i’m still not convinced of the approach you mentioned in your comment. The end result would be practically the same, and i wouldn’t really get any benefit out of it (and it would hurt backwards compatibility which i have to take into account). The reason why i don’t really get any benefit out it is because nobody ever has a reference to a handler. A specific handler is instantiated by the IOC container whenever a request comes into the service layer, and the Handle(Request) method is called, after which the resulting Response is just returned. You never instantiate or deal with a handler yourself, so the fact that the IUnitOfWork instance is exposed by a public getter/setter doesn’t really hurt anyone. Theoretically it certainly doesn’t have to be there and it shouldn’t be exposed. But if nobody gets the chance to actually access it (apart from the IOC container that provides the dependency), is there really a problem?

As for the SRP thing… i guess it depends on how strict you are about it. For me, a specific handler class will only have code to take care of the functionality it needs to provide. Nothing more, nothing less. It doesn’t need to worry about the UnitOfWork or the database transaction and automatic commits/rollbacks. Whether that is achieved through inheritance or composition doesn’t really matter to me so long as there is no noticeable downside to it.

that said, i do enjoy these sort of discussions so please feel free to share your other variations

The first step is to change the signature for your template method body from base.Handle(request) to base.Handle(UnitOfWork, request), allowing you to remove the derived type dependencies on the UnitOfWork property. Next, just to enforce that change, take the getter off the UnitOfWork property, or at least make it private to the base type. Then, replace inheritance with composition. Instead of deriving to implement Handle(UnitOfWork, TRequest) you instantiate just one implementation of a request handler and then call Handle. Handle would do your familiar transaction setup and then call a closure of the form TResponse Handle(IUnitOfWork, TRequest). The closure itself would assume operation within a transaction that commits on successful return and rolls back on any exception thrown from the closure. The closure would have been passed into the call to Handle itself, assuming the Handle signature can be modified, or passed into the ctor (if you are using a container that supports dependency override (StructureMap does, for example)) if the Handle signature cannot be modified. If it cannot, the ctor injection would do nicely. If your container can’t do dependency overrides, either get one that can or use setter injection for the closure.

Now, all of that said, if you ended up back at setter injection of a closure instead of setter injection of the unit of work, one would have to consider if the improvement of killing the SRP violation was worth the trouble. With that in mind, much of the above hinges itself on whether or not you can change the signature of the Handle method to accept the closure or your container (and instantiation pattern) will allow you to use ctor dependency override.

As for “I really don’t see this is as a violation of the Single Responsibility Principle.”, addressing unit of work and transactions is a separate concern from request-specific handling logic, and your current use of Template Method pattern simply proves the existence of the SRP violation, as much as it is occluded behind the responsibilities of the base type versus those of the derived types. That said, your current approach certainly isn’t a huge SRP violation and there may well be more pressing matters to hunt down within your codebase since your application of Template Method does a good job of minimizing the visibility and impact.

You could for the moment just do part of the change, as a prep move and a valuable piece of clean-up in its own right: the first two steps, changing the base.Handle(request) signature to also accept the unit of work and then hiding the UnitOfWork property from the derived types (and from outside code, which has its own benefit.)

that actually is a real-world example

how would you change the design so that the handler executes within the scope of the UnitOfWork _and_ has access to it? I could’ve gone the AOP route (either dynamically with Windsor or statically with Postsharp) but then i wouldn’t have access to the UOW in the derived handlers. If you have anything else in mind, please do share

Also, classes that derive from this specific handler typically introduce another dependency for context-related data so it can easily be accessed in the handlers that derive from that.

I really don’t see this is as a violation of the Single Responsibility Principle.

I posted my thoughts here. Let me know your thoughts.

Niraj

in most cases, i’d agree with that sentiment… but not in the context of the example given in the post

Using propery injection to solve ‘noisiness problem’ is just akward workaround for the real issue – SRP violation.

Cheers.