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.
Related
Ive been doing a bit of research / reading into mvc recently and was just wondering what the main purpose is.
is it as some people say to seperate the logic from the html
or to create clean url's
i could be missing the point completely, but asp.net forms really seperates the logic from the html and if you just want clean url's why not use a mod_rewrite rule?
MVC is a software engineering concept which is used more widely than just in ASP.net.
In a nutshell it encourages strong separation of:
business logic (the Model) the code which does all the brute force work behind the scenes; dealing with the database, performing large calculations; and
user interface logic (the View) the code which presents information to your users in a pretty way.
The C is for Controller - the ligaments that bind the bones of the model and the muscles of the views and allow them to communicate with each other cleanly.
You are correct that 'normal' ASP.net uses code-behind files so that page markup is kept separate from the code that generates that markup (in contrast to languages like PHP where code is embedded directly amongst HTML), but MVC ASP.net encourages even more separation in the ways I described above.
Take a look at this tutorial for a more detailed discussion of the pattern. Also take a look at this SO question
The MVC pattern has nothing to do with rewriting URLs. ASP.net MVC might make this easier but that is not by any means it's main purpose.
Testability is a big benefit of using ASP.NET MVC. It is non-trivial to write unit tests for ASP.NET winforms. It is much easier to unit tests for Controllers.
If you are doing MVC correctly, your views should be very light, and a lot of your logic is implemented in the Controllers.
Let me compare the two for you:
Asp.net web forms
They matured the old ASP technology that was much more like PHP. Code and presentation were piled up in the same file. Asp.net web forms upgraded this model by providing a mechanism of separating the two. But they built on top of the good things that windows application developers had. The drag drop interface creation with control events just like they exist in a windows application. Event thought code was separate from HTML, they were not separated. You still reference a lot of view controls in your codebehind, hence they're still very much bound to eachother.
Therefore it was rather easy to start developing on Asp.net web forms. But non savvy developers soon got to a bottleneck they didn't know existed (like slow postbacks due to huge view state etc.). Technology used some tricks to make this work. But on a serious large scale application this became quite a problem. Developers had to mingle their code to make it work with Asp.net web forms framework. Their complex forms had complex codebehinds with hard maintainable code with complex state.
The good (as well the bad) thing were at that time rich server controls. Nowadays with web 2.0 they don't seem rich anymore since they don't actually support client side functionality as much as they should. So Microsoft decided to also cram in something else. Update panels. That made partial rendering (and Ajax) possible with almost a flick of a finger. But it came with a cost. Everyone that used (uses) it soon realised it's not a viable solution that a professional application could implement.
Asp.net MVC
Now we have a new technology that doesn't have much in common with Asp.net web forms except for its first part of the name. MVC framework actually does separate code from user interface (view). Controller actions (code that executes on any HTTP request) is kept small and doesn't do anything with visualisation (it doesn't bind data to certain controls etc.). Controller action barely prepares data for the view to either consume or not. It's up to the view. Controller code doesn't in any way shape or form reference any view controls or anything. They're actually separate in MVC.
Views on the other hand just display and provide data. They can be partially or fully rendered. They support Ajax functionality to the point that everyone would like to use. Actually everything is separated into basic little things. Divide et impera (divide and conquer) seems to be the save-line here.
There's not hidden functionality. No flirting with windows development. It pure request response framework. Developer has the ability to 100% control the visual aspect of their app. But for the cost of not having rich controls out of the box. Those may be provided by the community or some developers prefer to create per purpose controls that serve the process much better.
Which one is better then?
Both have their pros and cons. But if you decide to build a semi complex, modern and maintainable application I'd suggest you give MVC a go.
But if all you need to do is a 15 screens application (without any particular interface requirements) it would be much faster to create it using Asp.net web forms.
MVC is a design pattern. Its purpose is to separate business logic and presentation details.
ASP.Net MVC is a mechanism to create web applications using ASP.Net and the MVC pattern.
One of the features of ASP.NET MVC is the ability to use SEO friendly URLs to provide commands to the controller part.
You can do as you have stated but ASP.Net have provided you a mechanism to do this easier.
The way ASP.Net Webforms was designed is that it made it easy for you drag controls on to the web form and code the logic underneath. ASP.Net MVC is designed so you separate your concerns easier.
The URL part of the ASP.NET MVC framework is just a modern phenomena to produce search engine friendly urls. They've infact been around long before the Microsoft team decided to add them to the framework (which required IIS7 before it could be done with no IIS extension).
The greatest pros in my view come from being able to test more easily, and separating off the parts of your application more cleanly. The whole ActionResult architecture of the ASP.NET MVC framework makes it very easy to switch from AJAX to plain out POSTs.
Delphi 5 use to employ the MVC model for its ISAPI extensions, 10 years ago.
MVC is not just an ASP.net thing, it is a design pattern that was widely accepted before it was created within the .NET framework, the thing about MVC is the separation of data from presentation(user interaction) from the business layer. It was just a way for Microsoft to offer that type of design pattern under the .NET framework
Although guys before me already give enough answers to the queston of purpose of ASP.NET MVC there is one thing I would like to add.
The ASP.NET Web Forms tried to abstract html and web from web development. That approach lead to the lacks in performances and usage of rich javascript frameworks.It was possible to create web application without actual knowledge of the web.
And to answer to you initial question, the purpose of ASP.NET MVC, I'll quote Dino Esposito:
With ASP.NET MVC, you rediscover the good old taste of the Web—stateless behavior, full control over every single bit of HTML, total script and CSS freedom.
MVC existed long before people tried to use it in HTML pages. The main reason for MVC is to get a grip on the logic to drive your application. MVC allows you to clearly separate things that should be separate: The model, code which converts the model value for the display and the code which controls the model.
So this is not related to HTML or URLs in any way. It's just that MVC makes it really simple to have clean HTML and simple URLs.
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've noticed a lot of talk about asp.net MVC lately, but I haven't come across a clear or compelling description of when, where or why I would want to use it over WebForms.
Let's say I wanted to build a small web application that allows a person to advertise some items online. The website will have 4 use cases:
Search adverts
View listings
View item
Place an advert
Let's assume:
I'm not particularly interested in unit testing my controller. The page will either render the list of items correctly, or it won't.
I am interested in more control over the HTML markup.
I'm not interested in using the latest buzz technology just for the sake of it.
I am interested in using the tool that is best suited to the job in terms of productivity, performance, maintainability & simplicity of the end solution.
I don't want to have to work around a bunch of nuances to get something simple to work.
So, my questions are thus:
What are the fundamental differences between the two models?
In which scenario is one better than the other?
What are the gotchas with asp.net MVC (I'm aware of the gotchas with WebForms)
For our sample app, what would I gain by using asp.net MVC instead of WebForms?
For our sample app, what would I lose by using asp.net MVC instead of WebForms?
Is it feasible to mix and match models within the same small application?
Thanks to anyone who spends the time to contribute an answer.
What are the fundamental differences between the two models?
WebForms try to mimic WinForms development by allowing you to reuse lots of pre-made controls, and by faking web application state via the hidden _VIEWSTATE mechanism.
MVC is a pattern designed to help you separate your data (Model), business logic (Controller) and presentation (View). It adheres more to the true nature of the web : RESTful URLs, stateless.
In which scenario is one better than the other?
In my opinion, for an intranet application making heavy usage of controls, WebForms can be useful at reducing development time, because thanks to the designer you can create your UI very quickly and let the framework manage the app's state automatically.
For any other project, especially a public website, even a small one, I think MVC is the way to go.
What are the gotchas with asp.net MVC (I'm aware of the gotchas with
WebForms)
I'd say there is some learning curve to fully understand the MVC pattern and its power. Also, since the framework is still in BETA you can expect the API to experience some minor changes before release.
Since JavaScript is not hidden from you in MVC, it would also require some time to learn if you're not familiar with it. jQuery greatly simplifies this though.
For our sample app, what would I gain by using asp.net MVC instead of
WebForms?
You'd gain better control over HTML markup and Javascript behavior, a cleaner separation of concerns and some easily testable codebase (even if you don't seem interested in unit testing it).
For our sample app, what would I lose by using asp.net MVC instead of
WebForms?
You'd lose the 'drag and drop' quick way of building your pages and the application state management.
Is it feasible to mix and match models within the same small
application?
In some ways, yes it seems.
I'd recommend watching this talk by Phil Haack, who gives a good overview of the framework and invites Jeff Atwood to talk about how he built StackOverflow with it.
He explains how SO is using some WebForms controls for CAPTCHAs which render themselves into the view.
The primary difference is that MVC is more like "regular" web development that the rest of the programming world uses, whereas standard ASP.NET was designed to make it brain-dead easy for Windows developers to become web developers. I learned web programming by learning Ruby on Rails, and MVC seems like it is becoming the .NET version of Rails.
MVC is much more oriented around standards compliance, unobtrusive javascript, and separation of concerns than regular ASP.NET. You'll need to understand how HTML and CSS work together. You'll learn a LOT more javascript as you master MVC. One of the biggest advantages of MVC to me is that you can use jQuery to do some amazing AJAX stuff easier and BETTER than you can in regular ASP.NET.
If you're just now learning web development then I strongly encourage you to learn MVC. You'll be able to transfer at least some of your new skills to other frameworks in the future.
If you're looking for which to learn to quickly get a web development job, then I'll have to strongly suggest ASP.NET.
Once MVC is RTM'd I think we will see a slow and steady adoption curve and as it matures MVC may become the primary framework for creating websites with ASP.NET. I hope so at least!
The biggest difference between ASPNET MVC and is WebForms is the lifecycle of an page, no difficult(unnecessary) postbacks, clean coding, enz.
There are no rules for that
???
REST-full website, Separation of logic
Design-time support, can't use third-party webcontrols
Please don't mix it together. If you really want to use the WebForms model you could use the MVP pattern, Billy McCafferty wrote exellent articles on that design pattern
I'm redesigning some of my applications from the MVP-pattern to MVC-pattern, not because MVC is better but I would like to use the newest techniques offered by MS(pattern itself is quite old).
When I first heard about StackOverflow, and heard that it was being built in ASP.Net MVC, I was a little confused. I thought ASP.Net was always an example of an MVC architecture. You have the .aspx page that provides the view, the .aspx.vb page that provides the controller, and you can create another class to be the model. The process for using MVC in ASP.Net is described in this Microsoft article.
So my question is. What Does ASP.Net MVC provide that you wouldn't be able to do with regular ASP.Net (even as far back as ASP.Net 1.1)? It is just fancy URLs? Is it just for bragging rights for MS to be able to compare themselves with new technologies like Ruby On Rails, and say, "We can do that too"? Is there something more that ASP.Net MVC actually provides, rather than a couple extra templates in the File->New menu?
I'm probably sounding really skeptical and negative right now, so I'll just stop. But I really want to know what ASP.Net MVC actually provides. Also, if anybody can tell me why it's Model-View-Controller and not in order of the layers of View-Controller-Model or Model-Control-View depending on whether you are going top to bottom, or vice versa, I'd really appreciate that too.
EDIT
Also, it's probably worth pointing out that I've never really cared for the web forms (AKA server controls) model either. I've only used it minimally, and never on the job.
.aspx doesn't fulfill the MVC pattern because the aspx page (the 'view') is called before the code behind (the 'controller').
This means that the controller has a 'hard dependency' on the view, which is very much against MVC principles.
One of the core benefits of MVC is that it allows you to test your controller (which contains a lot of logic) without instantiating a real view. You simply can't do this in the .aspx world.
Testing the controller all by itself is much faster than having to instantiate an entire asp.net pipeline (application, request, response, view state, session state etc).
Scott Guthrie explained it in this post "ASP.NET MVC Framework"
It enables clean separation of concerns, testability, and TDD by
default. All core contracts within
the MVC framework are interface based
and easily mockable (it includes
interface based
IHttpRequest/IHttpResponse
intrinsics). You can unit test the
application without having to run the
Controllers within an ASP.NET process
(making unit testing fast). You can
use any unit testing framework you
want to-do this testing (including
NUnit, MBUnit, MS Test, etc).
It is highly extensible and pluggable. Everything in the MVC
framework is designed so that it can
be easily replaced/customized (for
example: you can optionally plug-in
your own view engine, routing policy,
parameter serialization, etc). It
also supports using existing
dependency injection and IOC container
models (Windsor, Spring.Net,
NHibernate, etc).
It includes a very powerful URL mapping component that enables you to
build applications with clean URLs.
URLs do not need to have extensions
within them, and are designed to
easily support SEO and REST-friendly
naming patterns. For example, I could
easily map the /products/edit/4 URL to
the "Edit" action of the
ProductsController class in my project
above, or map the
/Blogs/scottgu/10-10-2007/SomeTopic/
URL to a "DisplayPost" action of a
BlogEngineController class.
The MVC framework supports using the existing ASP.NET .ASPX, .ASCX, and
.Master markup files as "view
templates" (meaning you can easily use
existing ASP.NET features like nested
master pages, <%= %> snippets,
declarative server controls,
templates, data-binding, localization,
etc). It does not, however, use the
existing post-back model for
interactions back to the server.
Instead, you'll route all end-user
interactions to a Controller class
instead - which helps ensure clean
separation of concerns and testability
(it also means no viewstate or page
lifecycle with MVC based views).
The ASP.NET MVC framework fully supports existing ASP.NET features
like forms/windows authentication, URL
authorization, membership/roles,
output and data caching,
session/profile state management,
health monitoring, configuration
system, the provider architecture,
etc.
Primarily, it makes it very easy to create testable websites with well defined separations of responsibility. Its also much easier to create valid XHTML UIs using the new MVC framework.
I've used the 2nd CTP (I think they're on five now) to start work on a website and, having created a few web applications before, I have to say its hundreds of times better than using the server control model.
Server controls are fine when you don't know what you're doing. As you start to learn about how web applications should function, you start fighting them. Eventually, you have to write your own to get past the shortcomings of current controls. Its at this point where the MVC starts to shine. And that's not even considering the testability of your website...
No more auto-generated html IDs!!! Anyone doing any sort of javascript appreciates this fact.
ASP.Net with it's code behind is almost MVC - but not - the one big thing that makes it not is that the codebehinds are tied directly to the aspx's - which is a big component of MVC. If you are thinking of the codebehinds as the controller - the should be completely decoupled from the view. The new .NET MVC rounds this out - and brings a complete MVC framework. Though there are existing ones for .NET already (see Spring.NET).
I looked through a couple simple examples such as this one. I can kind of see the difference. However, I don't really see how MVC uncouples the view from the controller. The view still references stuff that's in the controller. I do see how it makes it much easier to test, and that at least in MVC the controller doesn't have any knowledge of the view. And you wouldn't have to process the view to call methods in the controller. I can see that's quite a leap, even though at first glance it may not seem like much.
I do agree with #Will about fighting server controls. I've never worked in a situation where they were actually used, but many people I know who have, have run into quite a few limitations with them.
Article about ASP.net MVC Vs ASP.net Web form
http://weblogs.asp.net/shijuvarghese/archive/2008/07/09/asp-net-mvc-vs-asp-net-web-form.aspx