Today I am not strictly mouthing off strictly about the three things in the title, but more about the side-effects of their joy in a web application.
Two things have made me feel dirty while implementing a messaging solution in a web application while adhering strictly to Command-Query Separation.
- Why do I have a single controller SENDING messages (commands), and READING (reporting) data?
- What patterns exist beyond just a correlation id for notifying the user when their commands’ processing are completed?
The first one is the one on my mind today as I am testing the bits that send the messages to my Win service hosting my domain. The second one I will deal with in the next post.
My controllers look pretty typical:
public class ProjectController : Controller
public void ProjectController(IExecuteCommands bus)
public ActionResult New()
return View(new NewProjectViewModel() };
public ActionResult Create(CreateProjectCommand project)
My controllers are either reading or writing…why do I have the same controller doing both? The semi-optional service dependencies are a smell that I am putting too many responsibilities here. I already adhere to POST-REDIRECT-GET convention, so it seems unnecessary.
Why not split this into :
- ProjectController = Only GET requests
- ProjectCommandController = Only POST requests
Since the majority of actions are reads and we want take of advantage of conventions in frameworks like MVC for urls, we can just pull our state-changing actions into a separate controller and append the name with ‘Command’.
Commands abiding by some kind of naming convention, perhaps ‘Execute’ prefix, would simply be routed to the [ControllerName] + ‘Command’ Controller.
This would make testing simpler since I don’t have to satisfy unneeded dependencies for action testing.
What pitfalls do you see in making this a standard practice? Have you tried this and found problems? I’d like to hear any criticisms and comments you might have.
06-24-2010 4:00 PM