In this posting, I will discuss the motivation behind
keeping View code as thin as possible when using patterns such as MVC, MVVM,
and MVP.
Once the motivation is
identified, I will examine some ways to determine whether a View contains logic
that belongs in another part of the application. While the concepts that I will discuss are
applicable to most any pattern which favors a thin View, any concrete examples
that I present will center on ASP.NET MVC.
Design patterns that
include a Model, a View, and other
components such as a Controller, ViewModel, or Presenter are not new to
application development. These patterns
have, in fact, been around since the early days of building applications with
graphical interfaces. The reason that
these patterns emerged is simple – the code running closest to the user tends
to be littered with logic and library calls that center around implementation
details of showing and manipulating user interface widgets and when this type
of code is interspersed with application domain logic it becomes difficult to
understand and much more difficult to adequately test. By removing domain logic from the View, we
ensure that the View has a single responsibility of drawing the screen which,
in turn, makes our application easier to understand and maintain.
I was recently asked to take a look at an ASP.NET MVC View
because the developer reviewing it thought that it possibly had too much going
on in the view. I looked at the .CSHTML
file and the first thing that occurred to me was that it began with 40 lines of
code declaring member variables and performing the necessary calculations to
populate these variables, which were later either output directly to the page
or used to control some conditional rendering action (such as adding a class
name to an HTML element or not rendering another element at all). This exhibited both of what I consider the
primary heuristics (or code
smells) indicating that the View is too smart:
Member variables – in general, variables in View
code are an indication that the Model to which the View is being bound is not
sufficient for the needs of the View and that the View has had to augment that
Model. Notable exceptions to this
guideline
include variables used to hold information specifically related to
rendering (such as a dynamically determined CSS class name or the depth within
a recursive structure for indentation purposes) and variables which are used to
facilitate looping through collections while binding.
Arithmetic – as with member variables, the
presence of arithmetic operators within View code are an indication that the
Model servicing the View is insufficient for its needs. For example, if the Model represents a line
item in a sales order, it might seem perfectly natural to “normalize” the Model
by storing the quantity and unit price in the Model and multiply these within
the View to show the line total. While
this does seem natural, it introduces a business rule to the View code and
makes it impossible to test that the rounding of the result meets the
requirement of the business without executing the View. Within View code, arithmetic should only be
used for activities such as incrementing loop counters and calculating element
widths.
In addition to the two characteristics of a “Smart View” that
I’ve discussed already, this View also exhibited another heuristic that
commonly indicates to me the need to refactor a View and make it a bit less
smart. That characteristic is the
existence of Boolean logic that either does not work directly with properties
of the Model or works with too many properties of the Model. Consider the following code and consider how logic
that does not work directly with properties of the Model is just another form
of the “member variable” heuristic covered earlier:
@if(DateTime.Now.Hour < 12) {
<div>Good Morning!</div>
} else {
<div>Greetings</div>
}
This code performs business logic to determine whether it is
morning. A possible refactoring would be
to add an IsMorning property to the Model, but in this particular case there is
enough similarity between the branches that the entire branching structure
could be collapsed by adding a Greeting property to the Model and using it
similarly to the following:
<div>@Model.Greeting</div>
Now let’s look at some complex logic around multiple Model
properties:
@if (ModelPageNumber + Model.NumbersToDisplay == Model.PageCount
|| (Model.PageCount !=
Model.CurrentPage
&&
!Model.DisplayValues.Contains(Model.PageCount))) {
<div>There's more to
see!</div>
}
In this scenario, not only is the View code difficult to
read (you shouldn’t have to play “human compiler” to determine the purpose of
the code), but it also complex enough to be at risk for logical errors that
cannot be detected without executing the View.
Conditional logic that requires more than a single logical operator should
be looked at more closely to determine whether the condition should be
evaluated elsewhere and exposed as a single property of the Model. Moving the logic above outside of the View
and exposing a new Model property would simplify the View code to:
@if(Model.HasMoreToSee) {
<div>There’s more to
see!</div>
}
In this posting I have briefly discussed some of the more
prominent heuristics that indicate a need to push code from the View into other
pieces of the application. You should
now be able to recognize these symptoms when building or maintaining Views (or
the Models that support them) in your applications.
