Tag Archives: MVC 4

Data Annotations

One of the many benefits of separating the concerns of the models, views, and controllers in an MVC application is that each of the three components is able to contain all of the code with which it is concerned. This means, for example, that the view is only concerned with the user interface, and contains only the code that displays a page and data to the user. It doesn’t have any business logic, data access, or any other code unrelated to the user interface.

In the same way, an MVC model is concerned only with data and business logic, nothing else. It interacts with a data store, such as SQL Server, and takes care of all the CRUD operations for maintaining data. In theory, this helps maintain a clean separation of concerns with the other MVC components.

But not everything is always so black and white or neatly partitioned. One issue that would seem like it crosses the component boundary is data validation. On one side, a relational database has certain requirements for data, such as a ProductID that is an integer, and that a company name is a string of one to fifty characters, no more and no less. It may also mandate that every product be assigned to a non-null product category, and that a U.S. Zip code be either five or nine characters in length.

Beyond those data type sort of requirements, you may also have business logic that requires that an email address be of a format that meets the requirements of the Internet, or that no customer can receive more than five orders a year with greater than a 20% discount. All of these data and business logic rules are in place to ensure that stored data is of the highest quality and that the application doesn’t allow any violations of the rules by which the business operates.

But where and how should you define these rules? On one hand, they are the domain of the model because most underlying data stores have requirements that must be met to store data. And because an MVC model is the proper location for business rules, it seems clear that they go in the model as well.

On the other hand, however, it is usually the user interface that needs to take a hand in enforcing the rules and helping the user provide the correct data by displaying error messages when she tries to save data that is missing a field. An input field of type text for the company name might have the max length attribute set to 50, to prevent the user from even entering too many characters in the first place. The user interface clearly has a role to play in data validation.

So where should you implement data validation, in the view or the model? The good news is that with an MVC model there is a clear answer: the model. You add attributes to the properties and classes that implement the model that define the data validation rules, and you can add other data annotations that guide how the view should use the properties of the model. The view can then look at those rules and annotations, and then enforce the rules and appropriately modify how it displays the data to the user. The view’s role in data validation is to take the rules defined in the model—without defining any of its own—and provide a user interface that enforces those rules.

Best of all, since the rules are part of the model, they’ll be in effect no matter where you use the model, across all views and controllers. There is no need to duplicate the rules anywhere in the application. This is an application of the DRY principle of an MVC application: Don’t Repeat Yourself.

James Curtis

This post is an excerpt from the online courseware for our MVC 4.0: Working with Data course written by expert James Curtis.

James Curtis  is a .NET Developer that primarily works in the UX space. He has worked on and for several large projects alongside Microsoft Consulting. James has spoken at several code camps about UX development for ASP.NET and SharePoint. He is an active participant in the development community tweeting and blogging about several topics in the UX area. James is an active consultant and is also assisting in several Start-ups contributing his UX experience.

Choosing the Right Actions

The job of the action invoker to select the appropriate action method is more complicated than may appear on the surface. There could be multiple overloaded methods with the same name in a controller, they may be decorated with different attributes that make their selection appropriate in some scenarios and not others, their action method name may be different from their class method name, and other complications. Designing an effective controller requires that you understand how the selection process works.

The first thing that the action invoker does is to look for the action portion of the route definition for the request. Using the default route defined in a new MVC application shown below, it is the name at the second position.

Even if the current URL doesn’t include the action portion of the route, the default route definition defines it to be the “Index” action.

Once the action invoker has the name of the action, it needs to map that action name to a method of the controller. The simplest case occurs when there is a single method in the controller class with a name that matches the action name. For example, in a new MVC application the Index action of the Home controller maps to the single Index method in that controller.

But what qualifies as an action method? Is every method defined in the controller a potential action method? Not at all. There are a few requirements that a method must meet for the action invoker to consider it to be an action method candidate:

  • It must be a public method and not marked as static.
  • It cannot be a method defined on System.Object or the Controller base class. In other words, it must be defined within your custom controller object, not inherited from another object. So ToString could not be an action method because it is defined on System.Object.
  • It cannot be a special method, such as a constructor, property accessor, or event accessor.
  • It cannot have the NonActionAttribute decoration. This attribute is handy if you want to include a public method in a controller but don’t want to use it as an action method.

Taking all these restrictions into consideration, the action invoker uses reflection to find all methods in the controller with the same action name as the action name specified in the URL and meet the previous requirements.

But here is where things get a bit murky. Through the use of attributes on the controller’s methods, there could be multiple methods with the same name, the action name could be different from the method name, and there may be a selector attribute that restricts which requests an action method can respond to. This can create a bit of a gauntlet that the action invoker must navigate in order to find the correct action method.

ldn-pledgerwoodThis post is an excerpt from the online courseware for our MVC 4.0: Controllers course written by expert Phil Ledgerwood.

Phil Ledgerwood has been a software developer for fifteen years. He currently works primarily in .NET technologies producing custom software for organizations of all sizes. He has also done extensive training for those same organizations in both technical and business process topics.