MVC Gaps
Back in the day, when MVC was originally described by Trygve Reenskaug as an architecture approach it was all about the users mental model, giving the user the sense of just working directly with the domain objects. Now dont confuse this with the dreaded CRUDy forms-over-data battleship grey enterprise app. Those apps force the user to manipulate the data directly; respecting, fighting and being forced into submission by the techniocal details of databases. MVC on the other hands puts that the model is the users mental model - the programmer, then has to deal with hiding the technicalities of persistence and such. As illustrated below the users works as if manipulating the domain objects directly. The view simply reflects the model state, the controller reacts to user actions, and translates them to model updates, and that's it.
 |
| Direct manipulation metphor as illustrated by Trygve Reenskaug |
Roles and Contexts to Fill the Gap
So we need something more than MVC: The view is not the place for the behaviour, the model is not the place for the bahivour, and the controller is not the place for it either. This is where roles as separate things come into play. We want explicit roles. We want those business rules implemented in the roles. And we want to assing those roles to domain objects as needed.
The role a given object plays at a given moment depends on the context at that moment. So why not introduce contexts as something explict along with the explicit roles? Together roles implementing behaviour and contexts assigning roles to objects fill the gap in MVC.
Back to APS.NET MVC
Lets get practical: Where do the contexts and the roles go then? Since the contexts manage assigning roles and kicking off the behaviuour the contexts and roles fit well together. In the ASP.NET MVC + DCI demo I did for ANUG I organized the code like this:
The Contexts folder has a subfolder for the use case I demoed. Other use cases would have their own subfolders. Inside the subfolder is the context for executing that use case, and the associated roles.
What is a role in C#? A role in C# is a set of extension methods on an interface (see this and that for more on roles in C#):
1 public static class TransferMoneySourceTrait
2 {
3 public static void TransferTo(this TransferMoneySource self, TransferMoneySink recipient, decimal amount)
4 {
5 // The implementation of the use case
6 if (self.Balance < amount)
7 {
8 throw new ApplicationException(
9 "insufficient funds");
10 }
11
12 self.Withdraw(amount);
13 self.Log("Withdrawing " + amount);
14 recipient.Deposit(amount);
15 recipient.Log("Depositing " + amount);
16 }
17 }
8 public class TransferMoneyContext
9 {
10 public TransferMoneySource Source { get; private set; }
11 public TransferMoneySink Sink { get; private set; }
12 public decimal Amount { get; private set; }
13
14 public TransferMoneyContext(TransferMoneySource source, TransferMoneySink sink, decimal amount)
15 {
16 Source = source;
17 Sink = sink;
18 Amount = amount;
19 }
20
21 public void Execute()
22 {
23 Source.TransferTo(Sink, Amount);
24 }
25 }
26
11 public class TransferMoneyController : Controller
12 {
13 AccountRepository accountRepo = new AccountRepository();
14
15 public ActionResult Index()
16 {
17
18 ViewData["SourceAccounts"] =
19 accountRepo.Accounts.Select(a => new SelectListItem {Text = a.Name, Value = a.Id.ToString()});
20 ViewData["DestinationAccounts"] =
21 accountRepo.Accounts.Select(a => new SelectListItem {Text = a.Name, Value = a.Id.ToString()});
22 return View();
23 }
24
25 [AcceptVerbs(HttpVerbs.Post)]
26 public ActionResult Index(FormCollection form)
27 {
28 var sourceAccountId = form["SourceAccounts"];
29 var destinationAccountId = form["DestinationAccounts"];
30 var amount = form["Amount"];
31
32 var sourceAccount = accountRepo.GetById(int.Parse(sourceAccountId));
33 var destinationAccount = accountRepo.GetById(int.Parse(destinationAccountId));
34
35 new TransferMoneyContext(sourceAccount as TransferMoneySource,
36 destinationAccount as TransferMoneySink,
37 decimal.Parse(amount)).Execute();
38
39 ViewData["Amount"] = amount;
40 ViewData["Source"] = sourceAccount.Name;
41 ViewData["Destination"] = destinationAccount.Name;
42
43 return View("Result");
44 }
45 }
Summing Up
MVC is great for simple situations. It doesn't quite scale to complex business scenarios, but DCI does, and the two are a great match.
Leveraging the power of C# to do DCI and the niceness of ASP.NET MVC to go along with it, makes for a - IMHO -very compelling architecte style for an enterprisy web app.