Imagine you are building the ASP.NET MVC Music Store from scratch. You start, as with all great applications, by using the File &cmdarr, 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.
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).
The Models folder is 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-drivendevelopment 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. You want to have the foreign key value for an artist embedded in the model for your album, because there will be a foreign key relationship between the table of artist records and the table of album records.
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 that 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 and some views and even create a database.