I'm aware there are a lot of topics about MVC design but it's hard to find good explanations: what I should do, what are the consequences of the different possibilities...

So I'm working on an ASP .NET MVC application with a HTML/Javascript front-end. Currently there is a view which allows the end-user to edit some objects like the others users. The form is automatically generated based on some meta-data. But these objects are rather complex, with many system properties and need to be edited by non-expert users. As we don't want to spend much time on the view, we decided to just hide all the input fields except the most simple ones like first name, last name, phone...

My question is, does this filtering should be done in the controller or in the view ? Should I Ignore the most complex input fields in the view or only returns the needed fields from the controller ?

Also my controller returns the data from the model without any post-processing. So it is done in the view. I could do it in the controller in order to save some ajax-calls and a little bandwith but I don't know if I should adapt the controller to the view or the view to the controller.

1 Answer 1


EEK... nooo my friend, hiding controls is the last thing you should do.

If your using MVC, and I assume (Judging by your description) the Model Binding syntax, where your forms are generated using Razor and the HTML Helpers, then your already half way towards letting MVC do all the work for you.

There are 2 main strategies when it comes to ASP.NET MVC.

Strategy Number 1 - Use ONLY the flattened models and properties you need to use.

In this scenario, you need to be using a well architecture, well tiered application solution, with different very separate levels of operation for things like presentation, Business rules, Data and possibly others too.

In your presentation layer, you model your objects to contain ONLY the properties you need to display, everything else such as system properties to control things you provide using property accessor's, functions/methods and a well though out abstraction of functionality throughout the entire object graph.

Your business layer, should take full objects containing everything from the data layer, and then flatten them, or combine them into single simple to manage objects, that contain only the information needed to do their job.

Doing things this way, requires a lot of planning up front, lots of fore thought, and leaves little or no room for scope creep or last minute changes, and if used fully is more suited to greenfield projects where you have total control from the beginning.

Strategy Number 2 - Use the ASP.NET Data annotation facilities

The ASP.NET MVC Model binder provides a fantastic set of attributes to control every aspect of your data model.

You can specify things like '[Required]', '[Min]', '[Datatype]' and much more.

Attributes are applied in the following fasion:

public myclass
  public string name { get; set; }

and are examined and acted on by every level of the framework.

In the case of my example above, if you used the razor form generators, you would get a form that specifies an input box for name, and if you tried to submit that form with no name supplied, the framework will tell you in your controller code that something was wrong, allowing you to pass the model straight back to the view without doing anything.

In most cases, it will also change the formatting and CSS for you to show that there is an error.

There's more than this though.

There are attributes, to tell a field that it's a hidden input, of a read only input, which means that when the model is rendered using something like '@beginform' these fields will automatically be removed from the display for you, again without you having to write a single line of code, or modify a html tag, css rule or attribute in the view page.

If you combine the 2...

Then things get even better, you have full fat models down in the code where it matters and where they are needed, and light weight models only containing whats needed for display in the presentation.

You can even go one step further, and using something like Angular, Knockout or Backbone, you can have your controllers return only JSON, then you can do your entire UI in an MVVM fashion.

This way you feed javascript object models that act like the code behind your view, and have your UI components update automatically based on these view models.

The beauty of using the JSON approach, is you can add as many different types of UI to your solution as you want.

Web browser for the desktop, mobile app for the phone, hybrid app for tablets, and plain old desktop standalone apps for the back room staff feeding data into the system, all working off a common set of JSON endpoints.

Here are a couple of links that provide some further reading as to what data attributes are available, and what it's possible to do with them.

MVC Tutorial part 6 by Jon Galloway

MSDN Documentation

Jon Galloway's entire series is well worth reading, Jon is a fellow pluralsight author and Iv'e had the pleasure of reviewing some of the material he's created for them, it's all exceptional quality and very informative.

  • Thank you for your very complete answer. In fact we have our specific framework to render the view so I'm going to consider the strategy number 1. Is creating anonymous objects containing only the needed data would be a suitable way to do achieve this solution ? If I understand well you also are suggesting in the strategy number 2 that I could serialize these objects in the correct JSON format expected by the view ?
    – Vincent
    Commented Jul 10, 2014 at 5:44
  • Your very welcome :-) and yes, point 1 is a valid solution. In fact it's industry practice. You should only ever treat your presentation as just that, and you should only ever feed it with exactly what data is needed. Let's take an example: If you had a full model from a users table that had passwords in, but you where not displaying passwords, would you still be happy that the model was in a place where just maybe someone could abuse it to see what user's passwords where? I can think of dozens more reasons too.
    – shawty
    Commented Jul 15, 2014 at 12:50
  • In point 2: This is the way the industry is leaning at present, with ALL the logic locked away behind a layer that does not have any display/presentation capabilities itself, and communicates only with some thin veil above that does only presentation. For the record here, I'm not advocating no logic in any presentation layer however, but I am advocating NO BUSINESS logic in presentation layers
    – shawty
    Commented Jul 15, 2014 at 12:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.