What requirements should each of these meet to be classed as either a Model or a ViewModel? (Aside from the directory they live in)
Thanks all,
Dave
Although Oded is correct in ViewModel not being part of MVC, many people still use that terminology to describe a model that is essentially one or a combination of translated data classes for presentation purposes.
In a typical implementation, the MVC Web project may not be able to have direct access to the DTO classes, it in turn calls a method in the Core layer which calls the database, retrieves the DTO objects and translates them into a "View Model".
I suppose it helps newcomers (who refer to their data classes as Models) distinguish between the DTO classes and classes built purely for presentation purposes based on the DTO classes.
A ViewModel is not part of the MVC pattern, to begin with.
It is part of MVVM.
The MV in both pattern mean Model (as in business/domain model) and View for the UI.
MVC also has a Controller, which is the orchestrator between the view and the model. In terms of the defaults of the Microsoft MVC framework, the Controllers, Views and Models each go into the directory of the matching name.
MVVM has the ViewModel which is a model of the view itself. Since this is not part of the MVC pattern, there is no place for these by default in the MVC templates by Microsoft, though if you wish to introduce this abstraction, you should create a ViewModels directory for them.
Related
I've noticed in ASP.NET MVC, it's commonplace to use model binding and validation annotations in conjunction with business objects that also interact with the database.
Unfortunately, this means that the scope of the request and the validation taking place must always be 1:1 with domain models. At the very least not without having to code a bunch of exceptions.
If I'm looking for a way to do contextual validation in ASP.NET MVC, are there any examples of or is it an accepted practice already to use POCO classes that represent the incoming data?
Let's say I call these "Request Models". An example might be that I create a class called UpdateUserRequestModel. I define only the data that I allow for a user update, then, I have MVC bind the values into this surrogate model. Later in my controller/services, I access the request model's public properties for the values I wish to move over to the user object.
So, the question here is: Is there already any example of this practice in commonly accepted ASP.NET MVC conventions? Does it have a particular name? Failing that, when I wish to do contextual validation, are there any better options than the default model binders and value providers that MVC ships with?
I do it on my apps. I validate actions the user performs, putting validation attributes etc on that view model that represents that action (conveniently models the form in the view and model binds the result on the way back). I even ported the ContosoUniversity app to reflect this style:
https://github.com/jbogard/ContosoUniversity
Background:
I have been thinking about this for quite some time and I haven´t found any good answer to it. After working for some time with WebForms and periodically with MVC 2,3 and 4 I still do not understand how ASP.NET MVC can claim to be an implementation of the MVC pattern.
One of the first thing I learned about MVC (pattern) is that it is cyclic - meaning that the View uses the Controller which updates the Model which updates the View - and this way it goes, round and round. Naturally with the User in the circle to input new instructions/data etc.
However, the ASP.NET MVC is not really a cyclic implementation, which is nicely demonstrated in the colored image below from W3CSchools. I have also seen this in practice where the View has an instance of a Model and the Model is updated from the Controller but where the Controller is also responsible for updating the View after the Model has been updated.
Question:
Is the ASP.NET MVC erroneously implemented by conscious and should it be seen only as a proprietary interpretation or have I misunderstood the rules of the MVC pattern?
The (Database) Model does not update the view, the controller updates the view while passing the View Model if you use separate view models (which you should)
Is it possible to call multiple stored procedures (not multiple result sets from a procedure) and display results on a single page in ASP.NET MVC 3 application?
From what I understand only one Model can created on any single page and my stored procedure is already tied to that Model. I would like to call another procedure and display that result as well on my page
I think the root problem is to understand the meaning of the Model in the MVC pattern.
First of all,
The model consists of application data and business rules, and the controller mediates input, converting it to commands for the model or view.[3] A view can be any output representation of data, such as a chart or a diagram
source
In ASP.Net MVC you link a model to your view, this model should not be part of your domain logic or any domain object
The real model (using the meaning of the MVC pattern) is represented by your domain objects.
So what should you put inside the object that you link to your view??
These objects should contain a representation of the view, in other words simple DTO's containing only the data that is going to be used in the view and nothing more. These models should represent the data being used in the view. If you follow this approach, and you need to display more data in the page, you only need to add another property to this model and voila, you can use it from your view.
In a CQRS architecture, these DTO's should be populated by the Query repositories.
If you do not have a CQRS architecture, just populate these objects in your domain, repositories, etc. Do not do it inside the controller, keep your controllers clean and simple, by making calls to your real domain using services or repositories
Try to avoid the reuse of these DTO's, they should belong to one view only. And do yourself a favor and do not try to reuse a domain object instead of a DTO just to use it as the model.
Following this approach your view-models will be clean, since they will be only DTO's and only containing the data needed by the view. And you can fill these DTO's from different sources, even from different databases if you want.
When you want to perform an action you would read from the model the data provided by the user, and with this data you would call your domain through repositories, services or in a CQRS arc. using commands
The simple answer to your question is "yes".
I suggest you do some more research (ie reading articles and looking at sample apps) into MVC and concentrate on understanding these points:
The Model is a class used to group the data you want to display in the View. It can be populated by a variety of methods and does not have to be the domain object or the pure representation of the database result.
A "page" (the concept of what a user sees in their browser window) can be made up from one or more Views. Each View can be responsible for displaying one type of Model allowing for reuse, but a "page" can have multiple Views.
Models are not "tied" to stored procedures. Perhaps you are using an ORM tool that returns a DTO class (which you call model)? This doesn't have to be the Model used by the View. The Controller could compose several of these DTO classes into one Model class.
N-tier application design where database access is separated from the display logic. MVC tries to encourage this but it still has to be done correctly to avoid tying yourself in knots.
Good luck!
I am trying to understand HMVC and how or if I should consider it in my current MVC app.
Regarding this quote from [this][1] question about MVC architecture,
Sometimes the Hierarchical-Model-View-Controller (HMVC) pattern (aka
Presentation-Abstraction-Control) is a good choice for dealing with
more complex interface and application demands.
"However, the traditional MVC scope falls short when it comes to the
control of GUI elements (widgets). MVC does not handle the
complexities of data management, event management, and application
flows. As an adaptation of the MVC triad, the HMVC --
Hierarchical-Model-View-Controller -- paradigm seeks to redress some
of the above-mentioned issues."
Jason Cai, Ranjit Kapila, and Gaurav Pal (July 2000). "HMVC: The
layered pattern for developing strong client tiers". JavaWorld
Magazine.
[1]:
https://stackoverflow.com/questions/113602/when-to-use-mvc-architecture
I have been trying to understand PAC/HMVC, and the above text struck a chord. The triad abstraction of HMVC can be applied to "widgets" on a page, or how in using the ASP.Net view engine (vs the Razor view engine), would translate to "controls" on the page.
Would that be an accurate application of the HMVC pattern?
If so, I'm not sure exactly how that would be implemented. I do see the advantages of this, in that if the main page loads fine, and some of the user controls/widgets error-out, the page still loads.
So the main page controller would make the call to its widgets controllers? From the main view, I am guessing that model inheritance would come into play, just as you would consume the model's objects in the view of a simple MVC page.
What would that look like in code - calling the model data from say two or three triads down the chain from a top-level view?
Firstly, you raise some interesting points. Secondly, I am making the assumption you are familiar with the ASP.NET MVC Framework.
Just thinking out loud here, there is a HtmlHelper called Partial(), which takes a controller and action and returns the result. So, if you write an Action that returns a PartialView (which could be used a widgets - you can have multiple per page), could this be a plausible implementation of the architecture above?
Thanks,
Matt
After reading different resources of HMVC, I believe ASP.NET MVC does have HMVC since v2.0 in the form of Areas.
Couple that with T4MVC and calling Action.PartialX() methods and you've got yourself the next buzz-word HMVC.
I'm creating a MVC base application, in the past I've alwaysed use Cairngorm as the framework for my Flex applications. For this app I'm experimenting with other approaches to mvc, not other frameworks (pureMVC or Mate), but writing my own MVC base application.
My question is in Cairngorm I've always created the model as a singleton, but what ways can I pass data from the model to the view and not use a singleton.
I was thinking of injecting the model into views or is another approach sending events containing data to and from the model to the view via the controller?
Thanks
Stephen
Personally, I think the easiest way to deal with this situation is to inject the Model directly into the View (via a constructor, or other mechanism).
Simple, yet effective.
I would declare the data as public properties. You almost always need to update data in a View based on user gestures, so using constructor arguments alone isn't very flexible and can be problematic for MXML-based Views.
Then you can either use binding expressions in the parent View to supply the data or use an IoC framework such as Swiz or Mate to inject the data. The disadvantage to the former approach is that you end up putting a lot of public properties in your parent views just so they can "relay" data to the child views. The nice thing about IoC is that you can add only the properties each View actually uses and then inject the data only where it's really needed.