Model Value in MVC

Question

Why is ASP.NET MVC sometimes using MODEL as part of an application that speaks to a database, for example here , and sometimes as a business object that “travels” through applications that provide data such as here ?

Answer 1

MVC has evolved in different directions since its inception, Smalltalk to the extent that it is often used to describe very fragmented architectures, as you discovered.

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

This explains the differences between MVC, MVP, and MVVM: http://joel.inpointform.net/software-development/mvvm-vs-mvp-vs-mvc-the-differences-explained/

My 10c:

Many ASP.NET MVC 3 examples are more closely related to the MVVM pattern than MVC. In MVVM, ViewModels are adapted for the specifics of the data for each view (that is, "ViewModels" are not only domain models, but are also decorated with problems of the presentation / presentation level, such as validation rules, tooltips / field names, field visibility, etc. .).

(Back to MVC). In smaller data centering projects that do not require multi-level completion, M may be as simple as an ORM model (e.g. .EDMX with some auto-generated POCOs) with several rules. In this case, MVC could be seen as the architecture of the application.

But in large projects using MVC, the original (Smalltalk) 'M' model is now split into several other layers, for example. domain objects, service facades, services (e.g. SOA), business and data layers, etc. (therefore, here M VC is a presentation level template, and M is the rest of your system). So, for example, in such a project, the Models folder of your MVC project can be simply proxied links to services and proximated domains that are used to communicate with the "back end" of your system or even with an abstraction of this message (for example, see the service agent / service facades used in the composite application block).

Answer 2

Because both of these things are part of what the Model component in MVC should use.

Roughly speaking, the roles of the three components are:

• The model implements all the domain logic. Usually this is due to constancy (for example, with a database), but also with business logic - in an ideal MVC, any modification of your domain data is implemented as a model subroutine.
• Controller reads data from the user interface (or regardless of what your open interface will be like), and sends it to the correct model program.
• The view transforms the raw model data into something that the user interface can present in an open interface.

Unlike the multilevel architecture, MVC does not distinguish between domain logic and data persistence: the model implements both.

In reality, however, most MVC implementations are not 100% correct. It is generally accepted that the model comes down to the level of access to data, and most of the domain logic occurs in the controller. In fact, it is sometimes unclear where the input check ends (Controller task) and the actual domain processing begins (Model task). There is also some controversy over how data is transferred from model to presentation. Does the controller read the model data and pass it to the view, or does the model actively transfer its results to the view? Or should the View be the active part when querying the model for the data?

Answer 3

In the Control Model Model Model Controller template, the presenter. It determines which view is being visualized and the data passed to that view.

In most cases, we are used to an architecture that uses a database to save the model. But this is not a requirement. A model can also be saved for something else (such as XML or web services).

M may also stand behind the view model. This means that you are not transferring the actual model from the database to the controller for viewing, but using a model specifically designed for presentation.

When using Domain Driven Design, your controller only acts to invoke features in your domain. The domain model contains the actual business logic and provides services for access to the persistence storage (storage) and the creation of new objects (factories). Then the controller should be as flat as possible.

Answer 4

Models are the most confusing part of MVC to understand.

Some people think in terms of a business model, so they do things like the fact that their model is directly connected to the database.

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

Personally, I have a second connection, because, in my opinion, this provides a better separation of problems.

Answer 5

In the first picture, you are informed that the controller creates the model from the database, then the model is passed to the view. The second is the same, but contains only a simple view.

You can check:

Understand MVC

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

Answer 6

I believe that this is the "business logic" or "the material that users receive from the site, and not how it looks."