While it may look like a Command object, I think that its purpose is entirely different. You can hijack it to execute Domain code, but that was never the intention.

Keeping the Domain action in the Controller is just a lot simpler, but I’m not sure I understand how this conflicts with Controller base classes and such (but I’m totally a “favor composition over inheritance” guy myself, so I don’t have any hierarchy when it comes to Controllers).

In any case, let’s take a look at your first attempt at DeleteRequestResult where you don’t like having to do Service Location. You are already injecting the Model and redirect action into the type, so why not also inject the repository and the logger now that you’re at it?

Not that I would inject the logger myself, though. Having the logger there violates the SRP. Logging is a cross-cutting concern and much better handled as such. Decorators are fantastic tools for implementing AOP-like features with DI, so I would rather prefer a LoggingDecorator that decorates that real action – that’s what we do at Safewhere, and it works like a charm.

.NET is just so much different. There are so many ways to communicate with a data store. In MVC, you have to do so much meta programming to do stuff that has nothing to do with solving your business problem.

> Service location in each of the ExecuteResult is not acceptable

Yes my suggestion would involve a single dependency that would resolve the invoker for the command. There may be more elegant ways – this was just a starting point for exploring ways of invoking the command within the action method. I could just as easily have the dependency supplied to the base controller class via setter injection, which is ultimately what you’ve done. Other times it makes sense to move key cross-cutting dependencies to a static service locator (things like event bus or SystemTime wrappers) and take a small hit in your test setup code.

You’re definitely onto something with the commands though – interesting to see how this progresses.

Yeah, at that point it’s probably a preference thing. However, I don’t ever want to add a dependency to a base controller type. If an entire family of Save actions now needs some extra thing to do its work, I don’t want to add that dependency to all derived classes. Just the difference btwn inheritance and composition.

Even though the dependency on the container has been technically avoided here, the code still depends on a fine-grained interface that only container can satisfy. Removing the whole notion of a container. Is what you want. Then wire up the container on the side.

CodeCampServer has some examples of regular abstract factories

Both of these solutions require a layer supertype controller with a dependency. The whole reason I moved towards something executing a parameter object (think of it as a message, and IHandler) was so that each handler could have its logic contained independent of all other handlers.

@Dan

We’re up to 8-9 custom ActionResult objects. Service location in each of the ExecuteResult is not acceptable. Neither is putting all of the logic down into the base controller, I don’t want layer super type dependencies, it just doesn’t scale.

@Zeus

That works, but it’s not an improvement. I now have more moving pieces in a controller action, making it harder to test. WIth a handler separate from the message, I can allow the structure of the message and creation of it grow orthogonal to the logic handling the message.

My idea is replace
public ActionResult DeleteMethod()
{
//ViewData["Message"] = “Welcome to ASP.NET MVC!”;
return new DeleteResult({ … })
}
with

public ActionResult DeleteMethod()
{
//ViewData["Message"] = “Welcome to ASP.NET MVC!”;
return Kernel.Resolve({…})
}

now we are constructing the ActionResult via Dependency Injection

So DeleteResult can be defined as
public class DeleteResult:ActionResult
{
public IMyLogger MyLogger{get;set;}
public IMyRepository MyRepository{get;set;}

public override void ExecuteResult(ControllerContext context)
{
MyLogger.DoSomething();
MyRepository.DoSomething();
}
}

I think this is a more simple way to use a dependency injection.
Of course controller must have initialized property “public IKernel Kernel {get;set;}”, which is easy implemented when ControllerFactory is made as in the blog article – controller is obtained via IoC container.

Because DeleteAction is created with IoC it should be registered in it with “Transient” lifestyle.

Is our humble ActionResult the best candidate though? To me their responsibility should be restricted to the delivery of UI functionality according to the outcome of the “meat” of the controller action. They have a nice tightly focussed role and I’m just not sure if it’s a good thing to be highjacking the ActionResult execution mechanism to execute the main body of your application / business logic.

Wouldn’t the following controller logic be cleaner?

1. Issue a DeleteRequestCommand. This gets executed by DeleteRequestInvoker (controller has dependency on an ICommandInvoker, which finds relevant Invoker)
2. Controller receives a DeleteRequestResult that informs us of the outcome of the operation
3a. If result.Success then return ViewResult to render the “well done” view (or RedirectResult to get back to previous screen or something)
3b. If not, return ViewResult to render the “sorry guys” view to display contents of result.Problems collection

The main business logic coordination belongs in the command / invoker. The controller’s responsibility is to decide what to do in the UI according to the outcome.

With a consistent convention for commands and their results and the following helper method in your controller base class…

protected ActionResult ExecuteCommand[TCommand,TResult](T command, Func[TResult,ActionResult] ifSucceeds, Func[TResult,ActionResult] ifFails)

… controller action code could probably be limited to 1 or 2 lines.