BTI420 notes – Wed Feb 5

Data annotations overview

Data annotations are descriptive text attributes that we add to properties in a class. A data annotation is located just before/above the property declaration.

Data annotations can help with:

property constraint and limits

input data validation

property display and formatting in views

communicating error messages to users

Some data annotations are intended only for design model classes, while others are for use with view model classes. And, some work with both.

Their overall benefit is to reduce the amount of code that has to be written to handle typical data management scenarios.

Please note that data annotations DO NOT replace the need to validate data against business rules and/or application logic. You still need to do that. Data annotations help most by improving the quality of input data, so that it can then be inspected for its integrity and appropriateness.

In a regular expression, sometimes you need the backslash character (e.g. \d). In a .NET Framework string, the backslash is a quote character. So, you either precede the entire string with an at sign (@), or use a double backslash (\\d).

The System.Web.Mvc namespace adds some other useful data annotations. One that’s commonly used:

[Compare(“OtherProperty”)](compares the property with “OtherProperty”; they must match)

There are a few other data annotations, or parameters for them, that you may use occasionally; we may discuss them later in the course. They include ScaffoldColumn, DisplayFormat, ReadOnly, and HiddenInput.

.

Custom error messages

All attributes accept a parameter named “ErrorMessage”. The value is a custom error message for the user. For example:

Introduction to the ASP.NET MVC validation process

Validation also happens server-side, when posted. The best thing you can do is to use ModelState.IsValid.

Validation problem?

Send the bad data back to the view (this is new; before we just returned to the index view).

.

What is AutoMapper? What problem does it solve?

If you studied the code in the DataAnnotationsBasic web app code example, you saw many lines of code that simply mapped or assigned property values between objects. When mapping between objects that have many properties (20+ for example), you’ll have at least a line of code for every property.

It is a convention-based mapper: When it maps between classes, it simply maps / assigns values if the property types and property names match. Easy. Non-matching properties are ignored. (There are many other features, and you will learn some of then later in this course.)

The search results appear in a list in the middle panel. Click/select the AutoMapper item, and click the “Install” button. This action will copy the AutoMapper library to your “packages” folder, and update your project’s “packages.config” source code file.

Now it’s ready to use anywhere, simply by adding a “using AutoMapper;” directive to any source code class file.

.

Configuring maps

The best practice way to configure and use AutoMapper is described next.

In your MvcApplication class (in the Global.asax.cs source code file), add statements that will “configure” maps. This action ensures that a map is available to any of your project’s classes. For example:

Mapper.CreateMap< source_type , destination_type >();

The CreateMap method defines a mapping relationship between two classes.

The first parameter is the “source” class.

The second parameter is the “destination” class.

.

Add these “configure” statements for every map that you think that you’ll need. Group them by design model class. You will need one or more:

Create maps “to” view model classes (from design model classes)

Create maps “from” view model classes (to design model classes)

For each use case and its view model class, create a map, from a design model class, to the custom-and-specific view model class that will service that use case.

Typically, you will have maps that “shape” the delivery of data to the view.

Also, you will have maps that enable a view to “add” or “update” items.

Occasionally, you can even map between view model classes, where both the source and destination is a view model class.

You will see that in the AutoMapperIntro web app code example, in the controller method that handles the creation of a new vehicle. There’s a mapping between a “VehicleAdd” class and a “VehicleAddForm” class. Very convenient.

.

Using maps

After the maps have been defined you can use the Mapper.Map<T>() method anywhere you need to (e.g. in a Manager class, or in a controller method). Sources and destinations can be an object, or a collection of objects. One statement replaces several. What a deal.