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)
Related
As mentioned in another answer, our use case for Webflow is a bit unusual. Instead of a traditional MVC approach driving UI, with a little effort we exposed SWF as a RESTful HATEOAS API (with some caveats). Our Views are Collection+JSON format with links modelling SWF transitions.
The problem is that SWF tightly binds to the MVC pattern of returning ModelandView, with the View states resolving a view and calling render(). As such till now our choices have largely been to expose the API via a JSP (yuck). We're looking to use Spring Boot (no JSP) and moreover use RestController and Spring Hateoas where instead we want to return ResponseBody<> or ResponseEntity<T> from a controller method, with that being an object formed from the View(state) - i.e. get the Model but no view and generate C-J or HAL+Forms or similar from it with transitions as Links.
We use XML flow definitions (essential to the solution) so I figure either I'd have to
Define a new Flow xsd with custom attributes and monkey with the ModelBuilder code and View implementation. Seems a lot of hackery.
Somehow define a do-nothing MVC view and defer to the customer controller for the HttpResponse when entering View, but how?
Write a complete custom FlowHandlerAdapter (this might help alter the POST-redirect-GET behaviour but won't tackle the ModelandView bit)
"Insert some more elegant answer here"
What is the best route to pursue?
Before this whole thing is considered lunacy, think what SWF brings to proper REST API exposure of business logic - not just another tedious boilerplate example of a CRUD repository API, but loosely coupled declarative workflow. I looked at Spring State Machine also but frankly it seems miles behind SWF on key aspects and doesn't help with state exposure as REST.
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.
For an ASP.Net MVC 3 website, which will be a big website( 6Month/men for the FIRST version). I'm searching what is the right approach to use the power of asp.net MVC and the power of EF.
The "power" I hope I could use of EF:
POCO generation
LINQ Queries to interrogate the database
The navigation between objects parents <-> children
The lazy loading
The "power" I hope I could use with MVC(regarding data):
Data validation
?? The usage of EF object as Strong type for my view?
But I've several concern:
The "recursive" serialization which will happen if I serialize my EF (with bi-directionnal links)for JSON, how to avoid this?
I cannot put validation attribute on POCO class
So, I know that my question is a little "generic", but I can't find a good link which point me to a direction to solve all problems which comes with the combination of those two tech, do you know a website or do you have already got those kind of problems?
The usage of EF object as Strong type for my view?
No this is not a power. In most cases this is just an issue which raises both your main concerns. Use specialized model views for your views and Json handling actions and you will be fine. If you worry about conversions between model views and entities check for example AutoMapper to simplify this.
Btw. lazy loading in web application can be issue as well. You almost always know what data you need to handle current request so load them directly instead of using lazy loading.
I've spent a lot of time working in Django, and have grokked the framework well enough that I have started replacing the original components (view engine, etc.) with my own custom components and the sky hasn't fallen down.
I've been looking at ASP.NET MVC, and been quite interested (I really like C#/F#) but so far have learned... just about nothing. I've been digging through http://www.asp.net/mvc/mvc4 without much success. I suppose my main questions would be:
What are the main moving parts in a typical workflow? Let's say a request comes in. Who takes it, does stuff, and passes it on to who else? In Django, for example, a request goes through the URL Mapper, Middleware, goes to a controller, which may dig through some models (via explicit function calls) and get some data, pass it into a template (also via an explicit function call) to be rendered and pass it back.
What kind of client-server coupling is there? For example, in many frameworks there is a explicit coupling of each HTML-form with a serverside-validator, with a model, with a database table, such that client side validation code is automatically generated. Another example is Quora's Livenode, which explicitly links client-side HTML components with their dependencies in the model, allowing changes in the database to propagate and automagically update client-side code.
I think there is no better answer to your first question than ASP.NET MVC Pipeline :
http://www.simple-talk.com/content/file.ashx?file=6068
explained in more detail here :
http://www.simple-talk.com/dotnet/.net-framework/an-introduction-to-asp.net-mvc-extensibility/
To your second question : answer is none. ASP.NET application dont even have to render HTML output, you can write your own viewengine to give any representation of the data, not consumed by browser, but any http (REST) capable device. The only things you can consider as coupling "conventions" (for model binding for example), but they can be replaced and extended in any way you like.
What kind of client-server coupling is there?
As rouen said, none.
I am not familiar with Django, but unlike other MVC frameworks (including Rails) ASP.NET MVC is very skinny in that it only implements Views and Controllers of the traditional MVC pattern. You are pretty much on your own for the model part. That means there is no built-in support for database creation, ORM, et cetera.
ASP.NET MVC does implement a bunch of plumbing to route requests to the appropriate controllers and even some binding of parameters (e.g. query string parameters, form values) when instantiating controllers but this binding is not to a full blown model. The binding in this context is usually either single values or "viewModels"
ASP.NET MVC also implements the plumbing to select the right view to render.
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.