ASP.NET MVC - How to explain it?

Question

I am trying to teach ASP.NET MVC to students (undergrads) that have been studying ASP.NET for the last 8 weeks (I know that doesn't sound like much time, but the class is 4 hours per day, 5 days per week with Labs, Quizzes, Exams, and Wrestles).

I haven't gotten the question yet...but I know it is coming...

When would I use MVC instead of ASP??

I don't have any real experience with ASP MVC and I can't find any sort of clear-cut answer on the web. Arguments such as "...the web is stateless and ASP MVC is a closer match etc etc" do not mean much to them. They are starting to notice that ASP has lots of controls that seem to simplify their markup compared to MVC.

I'm trying to give an honest spin, and any feedback would be much appreciated! TIA

Answer 1

To me, the MVC approach is a very different paradigm from the ASP Forms API. I think the idea of being "stateless" is a good way to explain a very broad topic in one word actually.

One of the major advantages that I've seen is that the MVC framework gives a lot of control over the design and the output of your page. For small projects, this may not be the best use of it, but for large projects, it scales very well because you can make different architectural choices that (personally) I find to be better, such as the way that the MVC framework separates logic from the view.

Also, if you're designing a site that has a lot of Javascript, the control you gain over output in the MVC framework can be very helpful because you don't have to worry so much about how IDs and other markup may be rendered, like you typically do in the ASP Forms framework.

The MVC framework is really a totally different way to design web sites. Personally, I think it is more beneficial for large projects, but I also started out in web languages where MVC was a more popular design choice to begin with.

That's just my 2 cents.

Answer 2

For someone with experience (and pains) in Winforms - the biggest difference is no more Viewstate. The state of controls on the form is kept on the client, in the browser and sent to the server for each request.

If you use Javascript, it is easier to make changes on the browser side, while the server side gets an easy way to look at the form as a whole without having to recreate controls binding.

Beyond all the nice things MVC provides - separation of view/code, testability - this was for me the key point to move to MVC.

Answer 3

Statelessness is a good one word to explain as already highlighted by the members. Apart from this ask the following questions to the students?

If they have to do the following with ASP.NET (no MVC), how easy will it be?

1. Test your views
2. Mock Http objects.
3. Viewstate reduction (by design)(
4. Substitute lightweight viewengine for .aspx.
5. Thorough separation of concerns.
6. Clean HTML
7. etc. etc..

Now explain asp.net mvc in the above context. There may be more to it. Atleast I think they will get the point, thought this may not be applicable to all project, but what's the harm if we are only gaining from this.

Answer 4

I always thought the ASP.NET MVC Framework was a bad name since its a Design Pattern.

The question should be :

When would I use ASP.NET MVC Framework over ASP.NET Web forms?

The Developer Experience

a) ASP.NET Web Forms tries to abstract away the stateless nature of HTTP from the developer. The state of GUI Elements, and or data is stored in the Viewstate/Session. Everyone Form does a postback to itself, basically mimicking the behavior of a WinForm event driven design.

b) HTML GUI Elements are further abstracted by Controls which can be re-used, bought from 3rd party vendors. This helps developers glue an HTML app together without to much JavaScript and HTML/HTTP Knowledge. Basically similar to the way you would develop VB / WinForms

c) You can do a good job implementing the MVC/MVP pattern in ASP.NET webforms. Look at the Patterns and Practices Web Client software factory to see how they did it.

d) Developing using WebForms you are generally changing the HTML (View) based on user feedback at the server. Most events (user clicks a button, edits a field) are handled at the server in a continuous postback loop executing whats called the ASP.NET Page Lifecycle.

VS

Browser controlled view (dont know what else to call it). All changes to the HTML based on user input is handled in the browser. You will be manipulating the DOM with Javascript.

Note: I basing this on the fact that ASP.NET MVC is most likely driven by basic HTML + Ajax

How I would personally choose between them (never having used MVC, just reading on it)

1) If I was to build a pure stateless front end using Ajax, Jquery, EXT JS type libraries ASP.NET MVC would seem the better fit. Although you could build this in ASP.NET Webforms it seems pointless since you not taking advantage of the Postback model and Server Controls.

2) If I were asked to build a new basic web application, I would stick with ASP.NET Webforms since i'm already familiar with it and know the whole page lifecylce.

3) If I were asked to build a Web 2.0 (hate that term) to have a next gen User Experience, I would probably go with ASP.NET MVC, and use JQuery / ASP.NET Ajax client controls.

4) Many companies have built up a solid set of WebForm controls to use. It would be costly to rebuild them all in a pure stateless ajaxy way :)

Answer 5

Apart from all the other excellent responses already listed. Webforms is an abstraction away from HTML.

When you want a html table of data, you put a "gridview" control on a page - what you end up with is "gridview" html, and quite possibly not exactly what you were after.

The shoe fits 90% of the time, but a lot of the time, especially when things move beyond a basic site that the controls don't fit. Using Webforms often means that you don't have full control over the final output that is rendered to the browser.

You can of course extend, or write your own grid control. But wouldn't you just prefer to write the html you want instead?

It's my experience that has the projects get more complex, and UI's get more complicated that you end up fighting webforms more and more often.

Answer 6

http://www.emadibrahim.com/2008/09/07/deciding-between-aspnet-mvc-and-webforms/