Skip to main content

The Trappings of Not Using View Models (Part 1)

While there will forever be a debate over the fruitfulness of using view models in MVC applications, chances are that an application of a reasonable size will end up requiring them. I don’t like to state this as a solid requirement, but I will present two good cases as to why you should almost always start with them.

 

Enumerable Models in Your Views

If you are developing with the MVC Framework, chances are that you’ve – at least once – seen an example demonstrate how simple it is to loop over a collection of objects. Heck, I’ve done it as an example and have even taken a stab at using it in production code. This is made easy due to the fact that we can set our model type in the View as such:

@model IEnumerable<Person>

Then, we simply iterate over the list and output the results to a page:

<ul>
@foreach (var item in Model.People) {
<li>@item.FirstName @item.LastName</li>
}

</ul>

This is great, right?

But, while this works in this simple scenario, it can end up being a bit of a trap, and if you don’t catch it too early, you can end up with a pile of quickly accruing technical debt. Why is this the case? There are a number of reasons:

  1. First, the page is now tied to a list of Person. I’ll talk about the deeper problem here in Part 2.
  2. Secondly, the model really only contains items in a list, but no properties about the list. Having the FirstName property on the row is fine, but how do you now communicate to the view that email addresses on this page should be hidden?|
  3. Okay, you could use ViewBag to set properties about the list, but what about computed properties?
  4. Okay again! You could store the values in the ViewBag, then compute the values in the Razor view, but then how are you going to test the computations without complicating your tests beyond reason?
  5. Lastly, our plumbing gets jammed up “thinking” about this list and the idea of passing around the list starts to move throughout our project and application services. In the long run, this means that there will be a lot more friction when you want to make changes.

 

A Simple Solution

Thankfully, this is by no means hard to overcome. Consider adding the following class to the project:

public class PersonListViewModel
{
public bool AreEmailsHidden { get; set; }
public List<Person> People { get; set; }

}

And we’re going to update our view to use the view model:

@model IEnumerable<PersonListViewModel>

And finally, we loop over a property on the model, instead of the model itself:

<ul>
@foreach (var item in Model.People) {
<li>@item.FirstName @item.LastName</li>
}

</ul>

And thus, a straightforward way – that doesn’t add much weight to your project – to prevent a whole bunch of technical debt from sneaking up in your views. There is a thin layer that is added without much effort, but our project is much more maintainable.

Stay tuned for next month’s newsletter when we talk about the second trapping of not using View Models. Until then, if you ever need any custom application development assistance, you know who the experts are – Imaginet! With over 18 years of custom development experience and over 2,500 successful engagements, Imaginet provides efficiency and peace of mind in developing custom software applications that are on time and within budget.

—–

Imaginet is your trusted technology partner who turns your business innovation ideas into reality. 18+ years | 1100+ satisfied customers | 2500+ successful engagements. Located in Dallas (Irving), Winnipeg, and Calgary. Services offered worldwide. Contact us today at info@imaginet.com or 1-800-989-6022.

imaginet-lets-talk

Imaginet

Imaginet is your trusted technology partner who turns your business innovation ideas into reality. 20+ years | 1200+ satisfied customers | 2500+ successful engagements. Located in the United States and Canada. Services offered worldwide. Contact us today at info@imaginet.com or 1-800-989-6022.

Leave a Reply

Let‘s Talk.

Let's talk!