Model
The model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller).
In Model-View-Controller (MVC), Model is where you encapsulate the application’s state (therefore, it’s the layer that responds to state queries). In the real world, the model is more or less a replica of your database ER diagram.
After giving it some thought I ended up with that best way to explain what model is by creating a mock application, I admit that this is nothing new since there’s a very good tutorial of the same mold done by Microsoft. The music store application, a neatly packaged walk through that I highly recommend nevertheless my goal here is just to give you another perspective I doing the same thing. So what is that we’ll be doing here? Well I thought we’d keep it simple and just create a simple newsletter application, where users, after registration can receive newsletters of various dinner menus. I won’t be implementing the whole thing, c’os I have a day job, but rather focusing the functionalities that allow me to explain my point.
In an ideal world, as a developer, you’d be able to sit down and create the classes design (how objects will interact) and draw the database (how your data is stored) all of this while pondering all the consequences. But the truth is when you start developing, especially small applications, you barely have to time to scratch since everything is expected to be ready by yesterday. I bring this point c’os it’s important in the sense that’s why most developers use the database design to create the model.
So if you consider these tables:

You could then create this as your model with some changes, in the database design I needed to create an extra table (UserFoodPreferences) with a 1 > n relationships, while in the class design I simply need to add a List to the ApplicationUser class (List<FoodItem> FoodPreferences). This has, obviously to do with the data structures that we have available for each type of development, while in SQL you have to rely on relationships to store complex data, in C# you have “native” structures that allow you to do. My class diagram would look something like this:

Because the model usually mirrors what’s in the database you can also use de ADO.NET Entity Data Model. The ADO.NET will definitely make your life much easier by generating the code that does all the plumbing for you.

Before I sign off, I’d like to remind you that although I talk a lot about the Model mirroring the database. It doesn’t have to be like that, you can actually define a model that has nothing to do with how it’s stored in the database. Actually that the whole point of MVC is to allow to separate the various layers. On my next post I will talk about Controllers which will allow to post some code that will exemplify some of the things we’ve just talked about…

Take good care of yourselves