Skip to main content

The Trappings of Not Using View Models (Part 2)

In the first part of this article, we looked at how using an enumerable as our strongly-typed model on a view can end up causing us some headaches. The example, a list of Person, further compounded the problem because the Person is likely an entity that is part of our database.

At first glance, it doesn’t seem too bad, and again in many online samples and presentations (I’ve done it!) it’s so easy to show how quickly you can go from loading data from the database to showing it in the view. But when you’re working on a real-world project, chances are you’re introducing some technical debt inadvertently if you’re pushing these objects straight up to the view.

Using Simple Models in Your Views

I don’t want to suggest that this is always the wrong thing to do. For example, I’ve created smaller, internal sites that have simple rules, simple models, and are only really accessed by admins. Chances are these types of sites are time-limited or static in features and won’t require a lot of revisiting. But when you get any bigger, how does it lead to problems? Let’s take a look at a few of the reasons why:

  1.  As a model that is part of our database, it’s harder to separate storage concerns from display concerns.
  2. The kinds of things we store in the database (purchase rows, product details, cost of goods sold) don’t always align with the things we want to display (presentment of an invoice).
  3. Our views will have to do “logic” and formatting types of things (FirstName + ‘ ‘ + LastName) where they can’t be easily tested.
  4. If our domain entities change (new property names) or we want to introduce new fields (FullName) we have to change everything up-and-down our project.
  5. We essentially end up with coupling of our view to tables in our database.

Now, it’s easy to think that our project could balloon with extra classes, but it’s really not that bad. We can use a pre-existing library to handle our mapping (such as AutoMapper) so we don’t even need to do any heavy lifting.

The Simple Solution

Again, like with the enumerable challenge in Part 1, this is an easy thing to overcome. A view model such as the following would remove the need to put any kind of logic in our views.

public class PersonViewModel
  public string FirstName { get; set; }
  public string LastName { get; set; }
  public string Email { get; set; }
  public string FullName
      return string.Format("{0} {1}", FirstName, LastName);

If all of a sudden the requirement is to display everyone’s name as “Lastname, Firstname” instead of “Firstname Lastname”, or to make the last name uppercase, or any other case, we don’t need to trod across all our views to correct it, we just update the view model and any view that is using it will be included in the change. Strongly-typing the view, or a property on the view model, to PersonViewModel then alleviates many of the above concerns with, again, only a thin layer of code.

This concludes our two part article series on the trappings of not using view models. Remember, if you ever need any expert custom application development assistance, you know who to turn to – 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. We’re always here to help!


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 or 1-800-989-6022.



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 or 1-800-989-6022.

Leave a Reply

Let‘s Talk.

Let's talk!