Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
In various articles on the web about ASP.NET MVC I've people mention that Microsoft's implementation of MVC is somehow different form the 'classic' MVC pattern.
But I've never seen anyone go into any detail on this, and at first glance I don't see how ASP.NET MVC is any different from what is described, say, here.
So my question is: does ASP.NET MVC really violate any MVC pattern principles?
The problem is really that MVC is a loosely defined pattern. The "M" could be interpreted as "everything in the business domain, from entities to business logic".
I wouldn't say that ASP.NET violate MVC, but rather interprets it loosely.
Some official MVC examples uses entity framework directly in the controllers which in my opinion is incorrect. Because then it doesn't act as a bridge between the model and the view. Instead it takes care of business logic (even if it's very basic logic) AND map the model info to the view.
ASP.NET MVC has something called view models which are not the M in MVC. They are instead used as an adapter between the model (or rather one of more entities in the Model) and the view, thus taking over a part of the responsibility that the controller has.
Generally yes, Microsofts implementation of the MVC pattern follows the main tenant of the MVC pattern. It has a Model, Controller and View that are responsible for slightly different aspects of the UI (remember MVC is a presentation pattern in this instance so it's only responsible for the UI (mostly))
Where Microsoft start to deviate is the introduction of some of the less clean (as in not 100% MVC) features, specifically
ViewBag
C# in the view (not razor as such but #helper
functions)
TempData
ViewData
Layouts
ViewModels
Some of the above are more contentious than others. Ultimately all these things are designed to speed up development, but move away from the idea that the controller builds a model that the view then renders (full stop).
Microsoft also has a tendency to explain MVC as a business logic pattern (as mentioned above it's a UI pattern).
So in the Microsoft world you often see example where the controller gets a model from (for example) Entity Framework does some business logic (business logic shouldn't really be in the controller) then passes it into a ViewModel (not really 100% MVC) and the view then renders it (manipulating the data using helper functions).
So they try and sell MVC as a one pattern fits all solution when it's not.
Although, I agree with other answers [in some respect], let me put it into a different perspective.
ASP.NET MVC is not a pattern but rather a framework in which you can write your software using MVC pattern, or rather its specific web-application version.
You shouldn't worry about Microsoft's implementation. Their implementation of MVC Framework has little to do with MVC pattern. To implement it, MS use many different patterns, I am sure. The key here, is to understand that MVC framework is not MVC. It allows you to develop using MVC pattern. And in this case, this pattern includes certain rules that you need to follow, like in other patterns - name controllers with Controller at the end, for example. But this is MS's implementation for you. So, you have View, Model and Controller. MVC Framework tells you, follow the rules and we will connect all these for you.
Now, if you go to MVC pattern as original pattern, all it tells you - separate view from controller and model. And separate model from controller. Because this way, you can reuse model and controller with different view, for example. Now, how you implement it - it is up to you. As long as it has characteristics I described above, this is MVC. So, again, MS gave you MVC framework, in which you have separate M-V-C. Therefore, when you write your M,V and C, you have separation which is original pattern describes. MVC framework takes care of the wiring for you.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I've been using MVC for over a year now, and I like it alot. I've heard of Knockout.js. How is the comparison between these two? Which is better?
MVC seems to have reached its maturity with MVC5, with alot of support.
I do not see knockout.js as well supported. There examples on their site do not even work in Firefox. However, I can see the potential of this since it is written in javascript, client-side, and possibly faster since its client-side, like ajax.
What are the advantages of Model-view-controller vs Model-View-View-Controller?
You should not be comparing Knockout.js to Asp.NET MVC. The only similarities are that they both use the same Model-View-Controller pattern.
Knockout.js:
Knockout is a standalone JavaScript implementation of the Model-View-ViewModel pattern with templates. The underlying principles are therefore:
a clear separation between domain data, view components and data to be displayed
the presence of a clearly defined layer of specialized code to manage the relationships between the view components
The latter leverages the native event management features of the JavaScript language.
Asp.NET MVC:
ASP.NET MVC allows you to build a web application as a composition of three roles: Model, View and Controller.
A model represents the state of a particular aspect of the application. A controller handles interactions and updates the model to reflect a change in state of the application, and then passes information to the view. A view accepts necessary information from the controller and renders a user interface to display that information.
As you can see Knockout.js is an MVC implementation for JavaScript while Asp.Net MVC is an MVC implementation for a complete web application from front end to server. These technologies can even (and very often) be used together to build well structured applications on both the front end and the back end.
You are comparing apples and oranges...
Since you are now familiar with ASP.Net MVC (and the MVC design pattern in general), it is time to take the next step and use a JavaScript MVC framework WITH it.
There are many choices, some popular ones include Knockout.js, AngularJS, Backbone.js, Ember.js, and many more. The site TodoMVC will give you a flavor of what is out there.
I'm new to MVP .
can I use tutorials created for asp.net MVC to learn MVP pattern foundations and basics?
or differences are too much ?
The 2 patterns are pretty different. The MVP pattern could be used with classic WebForms whereas ASP.NET MVC already integrates lots of the MVC pattern's parts in the framework itself. The separation of concerns is already present. If you want to use MVP with classic WebForms you will have much more work because the pattern is non-existent in the framework.
MVC is good for plain server side scripting. In MVC developers always try to keep the controller very lean. Mainly controller is for just selecting the appropriate model and reflect on the view. But in today's web applications the View part has radically changed and became complex enough to produce a big, fat and messy controller. So now we need a new place to put the user interface's complex control logic. Here the P of MVP comes in that is the presenter. So presenters are responsible for controlling the logic for a particular user interface component. Don't worry the controller is still here, named as Application Controller. Which ultimately responsible for switching between comparatively larger application components. So MVP can also be said MVPC(!!). BTW this was my way of understanding MVP and obviously not any ground rule. But Google has some very cool documentations on MVP.
This question already has answers here:
Closed 13 years ago.
Possible Duplicates:
What are MVP and MVC and what is the difference?
mvc and mvp pattern
Folks,
What are some of the benefits of using MVC over MVP? I like that I don't have to use a framework for MVP and can be implemented via interfaces and classes. I still get the separation of concerns that MVC has and I get unit testing. What are some benefits of using MVC over MVP?
I wasn't even aware of "MVP" but haack[overflow] has a pretty good looking article...
Everything You Wanted To Know About MVC and MVP But Were Afraid To Ask
At the risk that Haack blocks cross linked images...Haack says the difference is clear :)
alt text http://haacked.com/images/haacked_com/WindowsLiveWriter/MVCandMVPPatternResources_71CE/WinMerge%20-%20%5BMVP.txt%20-%20mvc.txt%5D_3.png
Since I have been scrutinized by my comments about duplicates, I will just reference this SO questions and leave it to the "higher powers" to close if they see fit :P
What are MVP and MVC and what is the difference?
People get too hung up on initials and TLA's sometimes.
If what Phil Haack says in his article is true, I thought I was using MVC in ASP.NET MVC, but what I am really using is MVP (or a tweaked form of MVC).
With MVC, it’s always the controller’s
responsibility to handle mouse and
keyboard events. With MVP, GUI
components themselves initially handle
the user’s input, but delegate to the
interpretation of that input to the
presenter.
But that's not what ASP.NET MVC is really all about.
If I handle mouse and keyboard events, I like to do it in the browser with jQuery. That separates the user interaction from the controller, and provides for better decoupling between the UI layer and the "business" layer.
If I need to update part of my page using an AJAX call or JSON call, I am still going to need to do that anyway, whether I call it MVC or MVP.
ASP.NET WebForms, for example,
attempts to emulate the rich client
development paradigm via the use of
ViewState. This is why many attempts
to apply patterns to ASP.NET focus on
the MVP pattern because the MVP
pattern is more appropriate for a rich
client application with GUI
components.
However, many web platforms embrace
the stateless nature of the web and
forego attempting to simulate a
state-full rich client development
environment. In such systems, a
tweaked MVC pattern is more
applicable.
It is clear that Phil views (a tweaked form of) MVC as a move to a more stateless, thinner client, whereas MVP places more responsibility on the UI layer for providing a rich user experience.
Whether this is a good thing or not is subjective. If ASP.NET is MVP and ASP.NET MVC is MVC, I'll gladly accept the MVC initials to give up things like viewstate and obtuse logic.
Greetings,
Apologies in advance that I have not researched this toughly enough to answer the question myself, but I imagine it would take me some time and I would rather know now before I invest more time in learning it. I couldn't find anything in my initial research..
Why use ASP.Net MVC if your already using a multi-tier architecture (Data Layer, Logic Layer, Presentation Layer)? Other than the fact the controller has more power than the logic layer.
Am I right in thinking I can use nHibernate and all my data access classes, entities, and mappings in the Model part of the MVC?
When using controllers, is it best to separate a lot of the logic into a separate class so I can call it from multiple controllers? Or can I call them from the controllers themselves, considering the fact that I would not want all of them to be Actions, just normal methods.
Thanks
MVC is not to replace N-Tier, it is a way to organize the presentation layer.
I would not say that the controller is more powerful than the logic layer. Instead, the controller (as a part of the presentation layer) should still call the logic layer.
Controllers should only prepare data for views and handle actions from views. You should still use your BLL.
Yes, NHibernate entities can (and they should be) be passed to the views.
This will you get you into some trouble. You should use flattened, null-safe DTOs a.k.a. view models.
Damien, you might want to read these 2 posts:
The Fat Controller
An Architectural View of the ASP.NET MVC Framework
N-tier is an archtitectual pattern, to enable reuse, seperaation of concerns and scalability of the key areas of your application.
The non UI layers (Business, Data, Facade etc.) should be unit tested and UI agnostic.
The UI layer is just one of these layers weather it be Silverlight, ASP.NET MVC, web forms etc.
MVC, like MVP is a design pattern that enables better testability of the UI Layer.
ASP.Net MVC is an out of the box framework that supports and enforces this pattern.
The pattern was arround an in use long before this framework.
But this is simply a UI layer choice, There should be no interaction with databases, services etc in the controllers, they control the state of the view using the model, Should not control the business logic, peresistence, transactions etc.
To answer your question on why use if you are already going multi-tier is that it makes for more organized and search-engine friendly URL's. Also, it is more of a standard pattern than the other patterns tend to be in ASP.Net. That makes it more developer friendly for those that are already using MVC on other platforms.
I will begin this question by admitting I am very new to MVC. The design pattern makes sense to me at a high level, but now that I'm exploring ASP.NET MVC, some of the architectural pieces are challenging my preconceived notions. Learning is a good thing.
I've been working with Oxite lately as a learning tool written by people at the company that created ASP.NET MVC and thus, an ostensible reference application for ASP.NET MVC.
But today I saw a blog post about Oxite by Rob Conery that says:
One of the things that the Oxite team
decided to do was to separate the
Controllers and Views into another
Project for what I can only assume is
the separation of business logic from
view logic. This can lead to some
confusion since Controllers are meant
to handle application flow - not
necessarily business logic.
This has thrown me for a loop. Is this separation a tenet of MVC and thus a mistake by the Oxite developers, or is it Rob's opinion? If the business logic belongs in the model, why did the Oxite team put it in the controller? How do I execute an action that is business logic if not in the controller?
Further to that, am I making a mistake using Oxite as a learning benchmark considering comments like Rob's?
Your business logic goes in your business layer. The controllers use the business layer to create a model for your views to render. A good example is the MVC Storefront application that Rob Conery has produced. Oxite is currently getting lots of bad press as it apparently does not make good use of the MVC framework.
The reason that you want a business layer that is separate from your controllers is you may want to reuse the business layer across multiple controllers, or even multiple applications. An example of this would be normal user functions for displaying data, and administrative function for updating and adding data. You may make use of the same BL components in both cases but have different controllers and views to render to the data. Model objects would be the same.
You could implement your business layer (i.e. the Model) with your entities, aggregates, repositories, and services. The services call the repositories, which pull data from your DAL in the form of entities.
This can be set in a single, seperate project which is nothing more than a DLL.
Next, have your MVC App, which is really your Presentation layer, and have it utilize your business layer project. the controllers will work with your Services, and pump the data those Services generate into ViewData which is then pumped into your Views.
The controllers should only deal with routing concerns, such as which views to display, based upon user input from forms, querystrings, cookies, sessions, etc.
there has been an uproar from the "MVC purists" community about the validity of Oxite being used an a good MVC example. The bottom line is, business logic should not be contained in controllers, which I am sure you will see as Oxite gets refactored over the coming months.