BTI420 notes – Tue Jan 27

Checkpoint. System Design Guidance. More about view model classes. Design model classes. AutoMapper. More HTML Form elements.


Quiz 2 is today

Quiz 2 is today. We will probably do it at the end of the timeslot, beginning at 9:30am.

The quiz will be ten (10) minutes in length.

You will answer two or three questions, on a single sheet of paper. The questions will cover topics, concepts, definitions, descriptions, and so on. Think about a question-and-answer session in a job interview. Those are the kinds of questions you can expect.


Checkpoint and brief review

We have completed two full weeks of the course. Some of the topics are familiar, but many are new. Let’s pause for a few minutes, and make sure that you have a good foundation.In this brief discussion, we’ll cover the important topics and concepts. If you have a question, please ask.

>>> You must be comfortable with the structure and coding approach for an ASP.NET MVC web app. Controllers, view models, and the Manager class are located in the Controllers folder. The Views folder holds user interface code. Do you have any questions about this?

>>> Many ASP.NET MVC conventions should be starting to be familiar, including naming conventions, singular and plural usage, route selection, and so on. Are you familiar with these topics?

>>> Comfort with collections and LINQ is important. How well are you learning these topics?

>>> Delivering content to the user (on a view) is a critical skill to have. Do you know how?

>>> Equally important, you must be able to get user data into your app. We will use a strongly typed view model object to describe the shape of the incoming data.


Journey through this week’s topics

This briefly describes the journey we will take through this week’s topics.

The System Design Guidance diagram will help us to write a larger and more complex app.

You will learn to take advantage of a “layered” architecture, to separate our concerns, and enjoy many other benefits.

More work on user interface components, especially lists.

Improving the quality of the incoming data.


System Design Guidance

system-design-guidance-mvc-v7In semester 4, we begin to use a worksheet named “System Design Guidance”, to help you begin the process of writing larger and more complex apps.

It presents a “layered” architecture, and you learn where to locate your source code modules within the architecture.

The worksheet is introduced and discussed today. You can begin implementing its ‘best practice’ principles in your work right away.

System Design Guidance V7 for ASP.NET MVC web app


The role of a view model class

We need to talk about view model classes. This is an important topic.

A view model class takes on the exact shape of the data you wish to work with in a view (as defined in the model-view-controller architecture).

A view model class can define the data that is delivered to a user.

Or, it can define the data that is gathered from a user.


What are view model classes? Why have them?

You have learned that a view model class takes on the exact shape of the data you wish to work with in a view.

The properties in a view model class are based on the properties in a design model class.

Our goal is to prevent design model classes from being visible and accessible in controllers and views. Instead, in controllers and views, we will use view model classes. This implies that we must map data between design model classes, and view model classes.

This will help to implement the “separation of concerns” principle.


How to create view model classes

View model classes, for this BTI420 course, should be written in the Controllers folder.

We suggest that you create a separate source code file to hold the view model classes needed for each controller. For example, assume that you have a “Suppliers and Products” domain model. Therefore, you should create a source code file named “Supplier_vm.cs”, and another named “Product_vm.cs”.

What classes do you write? The answer is totally and completely dependent upon your app’s use cases. However, there are some common and obvious use case patterns. Follow these suggestions as you write view model classes for your first few apps.

As just stated above, assume a “Suppliers and Products” domain model. A supplier can have zero or more products, and a product is always linked to one supplier.

Notice the use of the entity’s name in the classes. Notice also the inheritance chain.

List – a class that can be used in the user interface as a simple lookup list (e.g. drop-down list)

  • public class ProductList
  • For all kinds of users
  • Include the Id property, and one or two descriptive properties

Add form – a class that defines the data for an HTML Form

  • public class ProductAddForm
  • Designed for an HTML Form
  • Includes initial or default data, and any other content/data to help build the HTML Form (for example, the items that will appear in a select / drop-down list)
  • Do NOT include the Id property

Add – a class that can be used by public users

  • public class ProductAdd
  • For all kinds of users
  • To be used for add-new tasks
  • Therefore, include properties that must be present in an add-new task
  • Do NOT include the Id property

Base – for get-some and get-one tasks

  • public class ProductBase : ProductAdd
  • For public or trusted users
  • Adds the Id property to the ‘…Add’ class (and any other useful/required properties)

Base with associated object – for get-some and get-one tasks

  • public class ProductBaseWithSupplier : ProductBase
  • For public or trusted users
  • Adds the associated Supplier property, to enable richer data display

Edit – for update-item tasks

  • public class ProductEdit : ProductBase
  • For partially-trusted users
  • Includes all (most) properties that you allow to be edited

Full – to deliver all (most) properties of an object

  • public class ProductFull : ProductEdit
  • For trusted users
  • Includes all (most) properties that you allow to be viewed or edited
  • Can include computed or temporal properties

You do not have to write all these classes.

Conversely, you may need more classes to handle some use cases. Don’t be afraid of doing that.


What about design model classes, which describe our real-world entities?

Above, you were reminded that a view model class takes on the exact shape of the data you wish to work with in a view.

The properties in a view model class are based on the properties in a design model class.

In your project’s “Models” folder, create a source code file named “DesignModelClasses.cs”. This will hold one or more classes that describe real-world entities. The controllers (and views) will NEVER have direct access to these classes. The “Manager” class will have access to the design model classes, and convert (or “map”) a design model object (or collection) to-and-from a view model object (or collection).

Above, you assumed the use of a “Suppliers and Products” domain model to help learn about view model classes. Continuing that usage:

The design model class name for a supplier entity is Supplier. Singular.

Many view model classes could be created for this entity, including:

  • SupplierList
  • SupplierAdd
  • SupplierAddForm
  • SupplierBase
  • SupplierBaseWithProducts (notice the singular-to-plural naming)

Similarly, the design model class name for a product entity is Product. Singular.

Many view model classes could be created for this entity, including:

  • ProductList
  • ProductAdd
  • ProductAddForm
  • ProductBase
  • ProductBaseWithSupplier

So, how do you convert (or “map”) between a design model object (or collection), and a view model object (or collection)? It’s easy:

  1. Assume that you are using the same property names in both kinds of classes
  2. Then, assume that you have a design model object
  3. Create a new view model object
  4. For each property in the view model object, set its value to the corresponding property in the design model object
  5. Then, use the view model object in whatever way you wish

If you have five properties, you will have five property-setting statements.

If you have twenty-five properties, you will have twenty-five property setting statements. Oh.

Will it be fun to write that code?


What is AutoMapper? What problem does it solve?

So, converting (or “mapping”) between classes is tedious. Boring. Error-prone. Ugly.  Awful.


AutoMapper, by Jimmy Bogard, helps solve this problem. (Here’s his blog post that introduced AutoMapper.)

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.)

How do you add AutoMapper to your app?

Via NuGet: In Solution Explorer, right-click your project, and choose “Manage NuGet Packages”. A dialog appears. In the left-side navigator, click/select “Online”. In the upper-right “search” area, enter (and look for) “automapper”.

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 “Cars” 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.

For example:

  • Mapper.Map< target_type >( source_type );



More work with HTML Form elements

At this point in this BTI420 course, you have experience with these HTML Form elements:

  • input type=text
  • input type=submit

In this section, you will learn how to render these elements:

  • multi-line text area
  • drop-down list
  • list box, single item select
  • list box, multiple item select
  • radio button group (can choose only one)
  • check box group (can choose zero or more)













  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: