asp.net MVC framework?

Question

I am learning MVC and new to it. I have read some articles on MVC.

What I could understand was:

View is just front end that never directly communicate to Model. It always intrects with Controler.

Controller is a software component that will receive and respond to View and communicate to Model.

Model will have all programming logic, validations, database communications, services etc.

Is my understanding correct ?

I further want to learn:

where will be POCO classess in model ?

will model not became complex if all validations, db communication code and business logic will be there ?

If there will be muplitle classes/ libraries in model, will control able to talk to any of them directly ? and they will respond back to Controler and control will again communicate with View ?

thanks Thanks THANKS for helping and guiding.

Answer 1

Just the basics:

Model: These would be plain old C# classes (POCO) which would be stored in the database and retrieved when needed. Should be minimal to no logic here at all in my opinion. Things like establishing a database connection, IMHO, should be taken care of in the Controller.

View: Is the rendered HTML page based on the data retrieved from the database (your POCOs). This is where you will have all the logic for presentation. Eg: Using a master page. Inserting PartialView's.

Controller: This is where you have your business logic. This means handling the requests, getting you Models set up for you views (ViewModels).

It's just a abstraction between things to simplify/clarify things for/during development. But you will often have gray lines.

Here is a very simple example of how Facebook might render a user profile. First, a request for a given user would be handed of to the appropriate Controller by the server. The controller would then take the request, figure out which user's information is being requests, connect and retrieve the user data from the database, format the data/model appropriately and pass it to the View. The View would then render then simply extract the data from the model and render it into the view.

Answer 2

You can think of the View as a template. Data from your view will get filled in to spots that you designate in the view. The View can also be an input template, where you designate fields used for input and those fields get sent to the controller.

The controller does most of the hard work. All web requests go through the controller. The controller acts as a mediator between view and model. The controller passes the model to the view, the view takes the model and uses its data to populate it's fields.

The model is just a set of data objects that define your data model. Sometimes these will be stand alone classes that have no special features, sometimes they will be classes generated from a tool like Entity Framework.

MVC is just an framework that is designed to seperate your user interface into seperate components so that it is easier to maintain.

Answer 3

View is just front end that never directly communicate to Model. It always intrects with Controler.

The View is the front-end, yes. It should not alter the Model, but it needs to be aware of the model as it must get information from it. It receives the Model from the Controller, and it 'interacts' with a Controller by way of Links/forms it may contain.

Controller is a software component that will receive and respond to View and communicate to Model.

The Controller does not 'receive' the View, but it does receive requests which may have come from a View (not necessarily one of it's own views). So, it responds to Requests - not Views, per se. It retrieves the Model, and should handle calling Model methods to alter the model based on the Request ("communicate to model"). It then hands a Model off to the View to display.

Model will have all programming logic, validations, database communications, services etc.

Logic and services often may not be in the Model. Services should be separate (they aren't one of "M.V.C." at all), and Controllers are generally where your application-specific logic is contained. Validation might be defined in your Model (some purists don't like doing this), but displaying validation is done in the View. Database communications could be in your Model, or you might have Services which do that.

where will be POCO classess in model ?

POCO classes would be in your Model, yes. So would ViewModel classes (which are often POCO classes, themselves). The Model may have many classes which represent your data for different circumstances - including multiple ways to represent the same data, because of different places you are using them.

For example: You might have a "change password model" which represents some of the User object properties, and would be entirely different from, say, a "user profile display" Model.

Your Model objects that directly represent database items could be in their own Library, but your ViewModel objects would likely be in a separate library. Your Model should not be aware of your Controller or View. Although you will create ViewModel objects with your view in mind (only including properties that you need in the View), the ViewModel itself, even, should not have any code that ties it to your Views.