4

This question is a result out of the discussion HERE and was moved from HERE.

Is it really good practice to supply EVERY value you display in any view via a model?
Especially variables like the current username. Even Microsoft odes the following in their default template for the _LoginPartial in ASP.NET MVC 3+:

"Hello " + User.Identity.GetUserName() + "!"

I think this is OK to not supply this via a model as it is much better in light of maintainability. Or should you obay the "MVC rules" and add a model/sub-model to every page/model to supply such stuff and pass it around in your views and partials?

How do you solve such "problems" or what do you think is the best way of doing such stuff?

Inheritance would be an option: 

public class BaseUserModel
{
    public string UserName { get; set; }
}

Require every model to inherit from a base model like above containing such values.
But could that cause problems if you need/want to inherit another class for some model?

Community
  • 1
Christoph Fink
  • 141
  • 3
  • I don't think this is the case at all, considering - for example - a `ViewBag` object is not a model but it is used to transmit data from the controller to the view. – Jeroen Vannevel Apr 25 '14 at 15:48

2 Answers2

2

User is a model, in the generic sense of the word, even if not according to Microsoft's narrower definition in their particular implementation of the MVC pattern. You're not doing something like User.OutputGreeting(), so the model and view are still separated, with all the concomitant benefits. The only thing you're missing out on is some of the sugar provided by the framework.

It doesn't make sense to put in more effort and more complexity to do something "the easy way." Additionally, creating another model for something already provided violates design principles like single source of truth.

Karl Bielefeldt
  • 146,727
  • 38
  • 279
  • 479
0

Inheritance

I have used inheritance before as a solution for passing common data to many of the same pages (user, role, event tracking/logging, profile information, and other data). This is convenient in some cases, but not always ideal. For instance, you may add profile data to the base model for pages where they can add their email address, or display their profile picture, and this may be used on many pages, but many pages this model may not be used at all which would be a waste.

Container Model

A better idea in my opinion is to create models specifically for your view(s). This way you can add several different models to a single container model and each view can have their custom set of models without carrying extra models that are not needed for that view (unlike the inheritance idea). You then could include the profile model on views that require it, and exclude it on views that don't. One feature I particularly like about this idea, is that you can include sub-models for partial views that can narrowly focus on just that model and be re-used on many other views.

Model + Web API Calls

Another strategy I have used is a mix of models and Web API calls. A main model for the page, but certain parts of the page could get/set their data via an API call, this I have found is useful for smaller parts of the page or commonly re-used parts of the page. This may not be the best from a purest point of view, but I have found it useful in practical situations. The most common examples for me are usually grids or custom controls. I will have a model for the page, but some grids or controls on the page will get their data from API calls that typically return XML or Json and be manipulated via Javascript/jQuery.

Steven Kohus
  • 101