Responsibility-Driven Design defines two concepts that work very well in ASP.NET MVC: controller and coordinator. Needless to say, an RDD controller has little to do with an ASP.NET MVC controller. In RDD, a controller orchestrates the behavior of other objects, and decides what other objects should do. In one word, it suggests a chatty communication model. An RDD coordinator, instead, adds one more layer around controllers. A coordinator, in fact, solicited by events delegates work to other objects. In doing so, it applies a chunky communication model.
Great. What about ASP.NET MVC controllers? Should they be controllers or coordinators? Should they be chatty or chunky?
An ASP.NET MVC controller that chats with the site’s backend is not really better than a so much snubbed code-behind class. An ASP.NET MVC controller that behaves like an RDD coordinator groups all of the steps that form the implementation of the action within a single worker object. You place a single call to the worker object and use its output to feed the view-model object.
You break down the complexity of the task requested into steps and code them into a worker service that is 1:1 with the controller. The controller method is then as simple as
public ActionResult Index() { var model = _workerService.GetIndexViewModel(); return View(model); }
You have no need to test controllers any more and, better, pass any information down to the worker service which is completely isolated from the HTTP context.
Are you working on a new edition of Programming ASP.NET MVC book updated for MVC 4? The link and the title do not correspond. Thank you!
Hi Andrew,
right, a new edition of Programming ASP.NET MVC4 will be available in July/August. The link is just not updated yet.
Thanks for you reply, Dino! I think now MVC5 is more relevant and this is the book you are probably working on: http://shop.oreilly.com/product/0790145389428.do
Hi Dino, I would like a clearer explanation for knowing the difference between Domain Model, Domain Service & Repository.
Does Domain Service use Repository to get back Entities? Does Domain Service create the Domain model by adding business logic to the Entities?
It seems in you figure 7.4 Application Logic can use Repository directly, or use Domain Service which uses Repository. Does the application Logic get back at the end Entities? Then does it transform to a “View” model by transforming with DTO? And finally it would return this “View” model to the controller?
I think the best to be sure we understand your architecture would be to “translate” all the different parts in concrete code examples which would of course describe one possible implementation among others.
Thanks if you could help me and make sure I did understand some if not most part of what your exposed 🙂
Cheers from Pars