I have developed in the past always classic ASP.NET solution. I am starting currently to develop ASP.NET MVC solutions, but i have a problem understanding what a Model is and what it should contain.In the past i had an Object. For example one for User, Product and an object for Countries and one for Product Categories. Then within the class User i had a methods for retrieving a user, saving and updating it. The User objects properties where bound to Textboxes or labels on the .aspx page through codebehind code. Then the DropDowns for Country selection and the DropDown for Product Categories was also bound through the corresbonding objects.Now my question on the M > Model in ASP.NET MVC. What should it contain and what not? I mean the Model as my understanding needs to hold ALL information which are needed to render the page. Does this means that i will have a List<Countries> for the DropDown boxes and also User.CountryId both in within the Model? And even the ErrorMessage needs to be added to the Model when i throw an exception and want to show it on the same page? Or am i wrong? What is the difference between Model, ViewData and ViewBag? When to use what? Questions over questions but maybe someone can enlighten me :)
Can someone explain the Model in ASP.NET MVC?
asp.net mvc;model
The M in ASP.NET's MVC is better thought of as a ViewModel, which is an object that contains everything your View needs to render information to the screen. So a ViewModel is sort of specific to one page of your MVC application (although you can certainly reuse them for common pages).If you had a screen in your app, for example, that renders out a product's name, price, and description, and then has a text field to accept how many units a user wanted to order, the ViewModel might look something like public class ProductOrderTaker{    // these will be filled out by data calls    public string Name { get; set; }    public string Description { get; set; }    public decimal Price { get; set; }    // these are exposed to the user for editing in the view    public int UnitsToBePurchased { get; set; }}In your controller, in the initial GET loading of this page, you would new up an instance of this object, fill out the top 3 fields from a data call, and bind it as the Model for the View. The View would list the top 3 fields as labels (not form elements) and have a bound text field for the UnitsToBePurchased field. The POST version of the Action in the controller would accept this class as its parameter, and when it comes in, the UnitsToBePurchased field will have the value that the user filled out before posting the form.That's essentially the gist of it. Your Model/ViewModel just has properties for anything that's being rendered from data calls, and other properties to store the user input from that screen. Typically they do not posses lots of Business Logic, but rather your DAL or Business Rule lib will hydrate them or validate them separately.