Modeling the Music Store

Imagine you are building the ASP.NET MVC Music Store from scratch. You start, as with all great applications, by using the File ⇒ New Project menu command in Visual Studio. Once you give the project a name, Visual Studio will open the dialog you see in Figure 4.1, and you can tell Visual Studio you want to work with the Internet Application project template.

Figure 4.1

The Internet Application project template gives you everything you need to get started (see Figure 4.2): a basic layout view, a default homepage with a link for a customer to log in, an initial style sheet, and a relatively empty Models folder. All you find inside the Models folder is an AccountModels.cs file with some view-specific model classes for account management (the classes are specific to the views for registering, logging in, and changing a password).

Figure 4.2

Why is the Models folder nearly empty? Because the project template doesn't know what domain you are working in and it doesn't know what problem you are trying to solve.

At this point, you might not know what problem you are trying to solve, either! You might need to talk to customers and business owners, and do some initial prototyping or test-driven-development to start fleshing out a design. The ASP.NET MVC framework doesn't dictate your process or methodologies.

Eventually, you might decide the first step in building a music store is having the ability to list, create, edit, and delete music album information. You'll use the following class to model an album:

public class Album
{
    public virtual int      AlbumId     { get; set; }
    public virtual int      GenreId     { get; set; }
    public virtual int      ArtistId    { get; set; }
    public virtual string   Title       { get; set; }
    public virtual decimal  Price       { get; set; }
    public virtual string   AlbumArtUrl { get; set; }
    public virtual Genre    Genre       { get; set; }
    public virtual Artist   Artist      { get; set; }
}

The primary purpose of the album model is to simulate attributes of a music album, such as the title and the price. Every album also has an association with a single artist:

public class Artist
{
    public virtual int     ArtistId { get; set; }
    public virtual string  Name     { get; set; }
}

You might notice how each Album has two properties for managing an associated artist: the Artist property and the ArtistId property. We call the Artist property a navigational property, because given an album, you can navigate to the album's associated artist using the dot operator (favoriteAlbum.Artist).

We call the ArtistId property a foreign key property, because you know a bit about how databases work, and you know artists and albums will each maintain records in two different tables. Each artist may maintain an association with multiple albums. Because there will be a foreign key relationship between the table of artist records and the table of album records, you want to have the foreign key value for an artist embedded in the model for your album.

An album also has an associated genre, and every genre can maintain a list of associated albums:

public class Genre
{
    public virtual int      GenreId     { get; set; }
    public virtual string   Name        { get; set; }
    public virtual string   Description { get; set; }
    public virtual List<Album> Albums   { get; set; }
}

You might also notice how every property is virtual. I discuss why the properties are virtual later in this chapter. For now, these three simple class definitions are your starting models, and include everything you need to scaffold out a controller, some views, and even create a database.