Model meaning in MVC

Question

Why is MODEL in ASP.NET MVC sometimes used as part of an application that talks to a database like here and sometimes as a business object that "travels" across applications delivering data like here?

Answer 1

MVC has evolved in different directions since its Smalltalk beginnings to the point where it is often used to describe very disparate architectures, as you've discovered.

Martin Fowler blogs about the evolution of MVC here. http://martinfowler.com/eaaDev/uiArchs.html

There is an explanation of the differences between MVC, MVP and MVVM here: http://joel.inpointform.net/software-development/mvvm-vs-mvp-vs-mvc-the-differences-explained/

My 10c:

Many examples of ASP.NET MVC 3 are more closely aligned to the MVVM pattern than MVC. In MVVM, ViewModels are tailored for the data specifics of each View (i.e. 'ViewModels' are not merely domain models, but are decorated with View / Presentation Tier concerns such as validation rules, field prompts / names, field visibility etc).

(Back to MVC) In smaller data centric projects without much need for back end tiering, M can be as simple as an ORM model (e.g. an .EDMX with some autogenerated POCOs) with a few rules. In this case MVC could just about be regarded as an application architecture.

But in larger projects using MVC, the original (Smalltalk) 'M' of model is now split up into several other layers, e.g. domain entities, service facades, Service (e.g. SOA), Business, and Data Tiers, etc (so here, M VC is a presentation tier pattern, and M is the rest of your system). So for example in such a project, the 'Models' folder of your MVC project could simply be proxied service references and proxied domain entities used to communicate with the 'back end' of your system, or even an abstraction of this communication (e.g. see the service agent / service facades used in the Composite Application Block).

Answer 2

In the Model View Controller pattern, the Controller is leading. It determines which view is rendered and the data passed to that view.

Most of the time we are used to an architecture that uses a database to persist the model. But that's not a requirement. The model can also be persisted to something else (XML or web services for example).

The M could also stand for a view model. That means that the you are not passing the actual model from database to controller to view but that you are using a model that is specifically tailored for the view.

When using Domain Driven Design, your controller acts only to call on functions in your domain. The Domain Model contains the actual business logic and exposes services to access your persistence store (repositories) and to create new objects (factories). The Controller should then be as flat as possible.

Answer 3

I think of it as the "business logic" or "the stuff the users get from the site, not how it looks".

Answer 4

The first picture is telling you that a controller builds a model from the database then the model is passed to the view. The second one is the same but contains only a simple view.

You may want to check:

Understand MVC

DTO Pattern + Lazy Loading + Entity Framework + ASP.Net MVC + Auto Mapper

Answer 5

Models are the most confusing part of MVC to understand.

Some people think in terms of business model, so they do things like having their model talk directly to a database.

Others think in terms of view-models, so they end up with simpler data classes.

Personally, I'm with the second bunch, as I think it delivers better separation of concerns.

Answer 6

Because both these things are part of what the 'Model' component in MVC is supposed to do.

Roughly speaking, the three components' roles are:

• The Model implements the entire domain logic. This usually involves persistence (e.g. a database), but also business logic - in perfect MVC, any modification to your domain data is implemented as a Model routine.
• The Controller reads input from the UI (or whatever your public-facing interface is), and dispatches it to the correct Model routine.
• The View transforms raw Model data into something that the UI can present to the public interface.

Unlike the Multi-Tier architecture, MVC does not distinguish between domain logic and data persistence: the Model implements both.

In reality, however, most MVC implementations aren't 100% correct. It is quite common to see the Model reduced to a data access layer, with much of the domain logic happening in the Controller. In fact, it is sometimes unclear where input validation (the Controller's job) ends and actual domain processing (the Model's job) begins. There is also a bit of controversy about how data flows from the Model to the View - does the Controller read the Model data back and pass it to the View, or does the Model actively pass its results to the View? Or should the View be the active part, querying the Model for data?