Why MVC instead of good old ASP.NET? Still not grasping why I should go this route?

Question

I know this question has been asked before and I read all the answers but they still don't give me the answers I am looking for. I need something concrete. I volunteered to give a presentation on MVC to other developers in our group which forces me to learn it. The big question everyone has is: "What can MVC bring to the table that we can't do in asp.net or MVC can do faster. I have just gone through Nerd Dinner and actually created a complete website that sort of mimics Nerd Dinner. But as great a job that Scott Guthrie did on it, there are big gaps that aren't answered such as, how do I throw a textbox on the listing page with a button and do a simple search. In asp.net, I would throw a textbox, button and grid on the page and bind it to a sproc and away I go. What is the equivalent in MVC. I guess I need a really good tutorial on how to use MVC without using Linq-to-Sql.

I know I am sort of babbling on about this but it is a very serious question that still seems to go unanswered.

On a side note, the View page of MVC brings back nightmares of classic asp with all the in-line code that we got away from way back when with code behind pages. Yes, MVC has Controller and Model classes which are great but I still don't like the classic asp tags in the html.

Help me out here, I really like the concept of MVC and want it to be successful but I need more!

Answer 1

how do I throw a textbox on the listing page with a button and do a simple search. In asp.net, I would throw a textbox, button and grid on the page and bind it to a sproc and away I go

That's exactly the biggest problem behind "classic" ASP.NET aka WebForms.

You shouldn't be thinking in terms of pages, buttons and events.

You should learn the basics of how web works. Then you'd understand that the web speaks in terms of HTTP protocol, its commands GET, POST and others. Presentation is HTML, CSS and the Document Object Model which is where JavaScript comes into play. And there are in fact no pages, an url is just a pointer to a resource which is not necessarily mapped to a physical file (.html or .aspx) on the server.

the View page of MVC brings back nightmares of classic asp with all the in-line code that we got away from way back when with code behind pages.

I also came to MVC after staying with WebForms and I discovered I like the inline code very much. It makes the view structure very clear, which cannot be said about the coupling of static markup (aspx) + manipulating server controls in code-behind. The latter is actually a nightmare - your code is generating the markup output but you don't see where and how.

What can MVC bring to the table that we can't do in asp.net or MVC can do faster

It removes the ugly stateful abstraction which WebForms gave us. You're now back where it started. What you have now is:

• Option to separate your presentation part (views) from your application logic. Before there was all mixed together, code-behind talking to the database, calling other services, modifying the markup. It was mess. It resulted in lots of serious applications written but hardly maintainable any more.

• Ability to automatically test your application logic. With WebForms and code-behind, how would you invoke a certain scenario? You'd use tools like Selenium to mimic user activities. Now, when your views are just a passive presentation layer, you don't have this problem any more. You test your business logic and model output very easily. Views are there to display the results. If the model got the correct data in a particular scenario, the view will display it correctly. If not then not. Period. No need to test views.

• Control over your markup. That is if you care. If you a former Windows developer who doesn't give a damn about HTML documents being valid, being semantically correct and optimized for web engines, then it's of no use to you. I mean, "pages" are sort of displayed, user clicks are processed like in desktop application, what else, right? But if you were interested in all those things, then you'd look at the final markup output and see that it is ugly, with lots of errors, limitations which you simply can't fix. Because it's how controls, buttons, data grids etc. display themselves. An attempt to fix them would require to override markup generation of those controls which is a heavy task. Why don't just drop it and do everything manually?

What MVC takes from the table?

A server-side processing of "control" "events", like in Windows programming. If you're developing a desktop-like application for web medium, like those typical "business" software with dozens and hundreds of controls to drive you crazy, then MVC will drive you crazy, because you will have to wire each single control individually with JavaScript.

But if you're not developing those kinds of applications (which require certain mental abilities to work with), but developing modern usable software for web, then WebForms would drive you crazy. Sooner or later.

Answer 2

I was also learning MVC in the past few days. My experience is that is provides a much less complicated model of the web.

While WebForms promised that it will make web development very close to Windows development with a complicated event model, controls, and all the stuff.
Why? Because at the time Microsoft's developer base was mostly VB and C++ developers who were thinking in terms of forms, controls, and this provided an easy way for them to begin developing for the web.

What MVC provides is more control over the underlying protocol and more control over the HTML you output.
Plus, they give you ASP.NET routing built-in, so your URLs will also look and feel much better.

An example: StackOverflow was built using ASP.NET MVC.

Your example:

how do I throw a textbox on the listing page with a button and do a simple search. In asp.net, I would throw a textbox, button and grid on the page and bind it to a sproc and away I go.

You create an Action for it in the current Controller, throw a form on the page with Html.BeginForm which points to that action (remember, with MVC, you can have multiple forms on pages), throw a textbox and a submit button in it.

Then, according to your taste, you can either create a separate view for the search results, or reuse the existing view. The new action can be named the same as the old one, with [HttpPost] on it (or [HttpGet] if you prefer that), so the URL won't confuse the users more. You can then call your SPROC in your action and you are good to go.
(All this accomplishable in a matter of minutes.)

The other thing I like about MVC is that it is basically VERY EASY to create CRUD operations with it. (Like NerdDinner.)
VS generates 80% of the code required for your views, which then you can customise very easily.

I recommend you reading the whole book and not only the NerdDinner free episode, it gives you a very good picture about the technology.

Answer 3

The bulky Behind code is one the biggest issue with Webform. The RAD approach is good to create project faster but the growing bulky behind code is not maintainable , reusable and testable. There are 5 problems which MVC resolves of WebForm.

Problem 1 :- Webform was a View based solution for Action based requirement

Problem 2:- Tight coupling between behind code and view

Problem 3:- HTML is not the only response type in Webform it was not flexible

Problem 4:- Flexible Combination of view and data not possible with webforms

Problem 5:- Behind code was a heavy bulky class which can not be instantiated.

All the above points has been explained in this codeproject article http://www.codeproject.com/Articles/821275/Why-ASP-NET-MVC-ASP-NET-MVC-vs-ASP-NET-webforms

Answer 4

The following article got me started with MVC

ASP.NET web forms aren't going anywhere. As much as I love ASP.NET MVC, it is not the end-all-be-all one-size-fits-all solution to web development. Both of these approaches have their rightful place in a web developer's toolbox and it's important to recognize their strengths and weaknesses. In general, the ASP.NET MVC framework tends to sacrafice ease-of-use (e.g. viewstate, validation, etc.) in order give developers tighter control over the reins. This can be a great thing, but only if you take advantage of it. Otherwise it can just as easily be a hindrance.

With that in mind, I have developed a quick metric to determine if ASP.NET MVC is right for you. The way I see it, there are three primary reasons a developer should choose the ASP.NET MVC framework over ASP.NET web forms. If none of these reasons are compelling to you, then you should stick with ASP.NET web forms:

To Unit Test This, in my opinion, is the most compelling reason to use ASP.NET MVC. When it comes to unit testing, ASP.NET MVC simply blows ASP.NET web forms out of the water. It's not even close. Whereas ASP.NET web forms requires you to jump through all sorts of hoops to test around the page event lifecycle, the ASP.NET MVC framework practically begs to be tested. There are interfaces everywhere screaming "mock me!".

There's a reason why the biggest ASP.NET MVC supporters also tend to be TDD proponents; it's because ASP.NET MVC actually allows for TDD. Personally, I think this is where all the zeal comes from. Simply put: it's really, really hard to do TDD with ASP.NET web forms and really, really easy to do it in ASP.NET MVC.

To Gain Control and Extensibility As pointed out in the comments, ASP.NET MVC gives you more control and extensibility options than ASP.NET web forms. You get complete control over the page request lifecycle and the ability to substitute out several key pieces of the framework (e.g. view engine, routing, etc.), none of which is possible with ASP.NET web forms.

In addition to this, you also gain full control over the rendered HTML. In general, the rendered HTML from ASP.NET web forms applications is atrocious. The web controls it utilizes generate garbage ids and hidden fields galore that not only hamper the performance of a site, but also make CSS styling and Javascript development a pain. ASP.NET MVC forces you to be more in tune with your HTML. There aren't any repeaters or datagrids that magically generate markup for you. There aren't any hidden fields to persist state for you. It's just you, the HTML, and a few extension methods (which you don't even have to use).

To Learn Something New In other words, "because you feel like it". This was actually why I started using ASP.NET MVC. It never hurts to look at how you're approaching development from another angle.

I should also point out that learning ASP.NET MVC is incredibly engaging process since the ASP.NET MVC framework team has been so interactive in the process. I think a large part of the appeal of ASP.NET MVC is that the community's input is not only being taken into consideration, it is actively being sought after. The framework has sparked so many discussions and debates over best practices that simply following along introduces you to concepts you might previously have been unaware of. I would actually recommend learning the ASP.NET MVC framework for this reason alone. The threads on TDD, BDD, ORM, AJAX, etc. you stumble across during the learning process are worth it.

So there you have it. Aside from those three, I can't think of any other reasons why a developer would learn ASP.NET MVC. Maybe this is why the adoption rate isn't nearly as high as we think it should be. The incentive for using the framework essentially boils down to unit testing, control/extensibility, and boredom/curiosity. Good reasons, to be sure, but hardly game breakers for the vast majority of developers out there.

Answer 5

Control over the HTML output - is one thing. All those fancy controls SERIOUSLY SUCK from a SEO point of view.

Plus for COMPLEX forms, the ASP.NET state model is hell, too ;)

Anyhow, an example is your search box... it sucks ;)

I would use MVC like this:

Search is a URL: /search/keyword or /search/keyword/pagenr (like /search/programming/5

Good thing is: I can easily have search results spidered by google - some sites I Know get most hits from something like that.

Is it harder to program than asp.net - depends whether you want efficient HTML or not. THe control model from ASP.NET does not lead to lean defined HTML somehow.

Besides that - MVC is a lot more testable. Unit testing a classical HTML site is pretty impossible, the decoupled model of MVC makes that easier.

Answer 6

I don't come from a Microsoft background, so I might be missing something strictly related to ASP.NET but MVC isn't something different than ASP.NET. MVC, or model-view-controller, is an architectural principal in software design that isn't strictly for the web. Graphical user interface applications commonly use this model.

Anyway, your question is dealing with the "why". The search listing page is a good example to start with. With MVC, you can use templates to only modify the visual aspects of the search (the view). You can add buttons and format what the controller gives you without having to make changes to the controller itself. Similarly, with a view you can change the logic of what is "given" to the view without actually changing the view. Finally, you can go from a relational database to an XML database and without having to worry about changing any of the other aspects of your program. The logic is separated cleanly and this pattern fits many use-cases.

I would highly recommend seeing the Wikipedia article on MVC. It may be easier to understand using a graphical user interface (GUI) example instead of a simple web based example.

Ryan

Answer 7

MVC is considered as an alternative to good old asp.net, not the next step. IMHO MVC has a clear advantage if you want to write unit tests for your pages.

But I don't agree that MVC adds anything to classic asp.net in the name of performance, code quality or productivity. You can achieve same performance with asp.net by shutting down viewstate when not necessary or you can be more in control of HTML output by using lightweight server controls. (Repeater instead of DataGrid for example.)