<< Calling all Speakers – DotNetNuke OpenForce Wants You! | It’s Vegas Baby! >>

I Spose I’ll Just Say It: Still Waiting For a GOOD Reason to Learn MVC

Apr23

strawman_redherring

Why you shouldn’t learn MVC

Earlier today Rob Connery posted about why he thinks You Should Learn MVC. Rob is a great guy and we always have lively discussions whenever we meet at conferences. I was in the middle of writing a long comment on his blog when I decided it might be better as it’s own post.

I have to say Rob, once again, another great post! Another great use of straw man arguments and red herrings. Come on really? You are going to trot out jQuery as a reason to try MVC? Why not say “Use MVC because it runs on Windows and works with IIS”. Come on, at least use real arguments if you are going to make the case for MVC. I’m sure you know that jQuery works wonderfully with WebForms. People like Rich Strahl, Dave Ward and others have a ton of great blog posts on the topic. I even have a few myself. jQuery is a valid argument if you are trying to sell people on adding more JavaScript, but the argument as framed does not make the case for MVC.

Wow. You can use your own view engine in MVC. Good to see that MVC didn't break a basic feature we have had in ASP.Net since the 1.0 days. Nobody using ASP.Net is forced to use WebForms for page rendering. It seems that in Rob’s world, projects like Umbraco, Castle, and Visual Web GUI are the only people smart enough to figure that out. It is perfectly valid for a page or a control, or heaven forbid an HttpHandler, to use a different rendering engine for generating the HTML.

Non-validating Html - Really, that is the best you have? To paraphrase a quote from Rob - "Non-validating HTML is as Non-validating HTML does". If you want to write code that validates in WebForms, that is completely possible today. If you don’t care whether your page validates then moving to MVC isn’t going to make you suddenly start caring. I can throw a div inside a span and use capital letters in my attribute names and even use the bold tag and MVC will merrily spit it out to the browser. Sure, WebForms has a ton of crappy controls that will render garbage, but that is not the fault of WebForms. It is the fault of the control developers and the people who use those controls. There are lots of controls that render great markup – and people who care about their markup will either use a good control, or hand code their html.

Amazing, you can use IoC with MVC. Wow. I wish you could do that with Asp.Net and web form apps. It's is mind-blowing that all these IoC containers were written before MVC came along. Like they just knew that possibly someday, someone would be able to use them, if only MS would create a different web framework - or rather slap a different front end on ASP.Net. I guess I better stop using IoC with my webform apps since it is not possible.

I must say I agree with you about WebForms being one giant pile of abstractions, and frankly I am tired of it. Enough already. Let's get rid of these damned abstractions. Why, here I am using these alphanumeric characters, when we all know that it is just an illusion, a sham a hoax. There is no such thing as a character to a computer. There is only 1 and 0. Wait... that's not right either. There is only some voltage level that is not 0 and 0. or maybe it is 2 different magnetic orientations, or a pit and the absence of a pit. Whatever - I digress. We live and work in a world of abstractions. All of computer science is about abstractions. Rob has climbed the Mt Everest of abstractions and declared that one tiny snowflake sitting on the top is bad and must be replaced. You have suddenly declared that the top floor in our Tower of Babel is faulty and that this new penthouse suite is suddenly the one true path to heaven.

As for me and thousands of other ASP.Net developers, we are quite satisfied with our current abstraction. It makes it easy to do a lot of tasks. If I find the abstraction too leaky in places, then I push the abstraction out of the way and roll my own. Is this any different than what Chad and Jeremy did with FUBU MVC? But in most cases, I don’t need to go quite that far. I am quite comfortable writing an HttpHandler or an HttpModule for those cases where the webform defaults are getting in my way. I don’t require a whole new framework and a whole new mindset to get things done. I can use WebForms where they make life easy and dive down in the weeds when I really need fine-grained control.

Hey look at those nice URLs they generate in MVC. Boy, those are slick. No, really, they are. I’m not being sarcastic or anything. You really should check them out. But you know what – you can have them in WebForms as well. Scott Allen has a great MSDN article that discusses this very topic.

So enough already of the red herrings, the straw man arguments and the downright deceptive use of facts. How about a real argument about using MVC that doesn't first assume complete web illiteracy on the part of ASP.Net developers, but that somehow, if they use MVC those same brain-dead developers will suddenly become programming geniuses. If they were afraid to use jQuery before, they won’t use it just because they are in MVC. If they didn’t care about testing or HTML or clean URLs, MVC is not going to make them see the light. MVC is a tool. Good at some things, bad at others. In the hands of a master it will do great things. In the hands of someone who doesn’t care about his craft then MVC will be a nice diversion and yet another excuse for creating bad code.

So, lest you think I am against MVC, let me assure you I am not. I am against all of the same ol’ tired excuses about why people should jump to MVC. Every abstraction is about making tradeoffs, and make no mistake about it – MVC is an abstraction. Some people will claim it is a good abstraction, others will disagree, but at the end of the day the MVC team had to decide what was most important to them. Testability was clearly high on the list (Of course if you listen to Chad and Jeremy, it wasn’t high enough on the list). Clean URLs and a more restful like interaction was also important. Hiding the stateless nature of the web and leveraging reusable components – not so important.

So why should you at least learn MVC?

It will expose you to a different architecture. MVC definitely has its place – whether you are talking about desktop apps or web apps. MVC leads you to think about keeping a clean separation between different application concerns. It however doesn’t force you to do so. It is still possible for you to completely violate those rules, but it at least starts you out on the right path. WebForms on the other hand does not impose or suggest any such constraints. It is easy to get in trouble if you are not careful.

You will be forced to become intimately familiar with HTML and HTTP. This is great if you don’t already know it. I am a big believer in understanding how things work. However, for those that already have a good grasp of HTML this is a little overkill. I have a decent understanding of how the engine in my car works, but I don’t want to have to put it together every-time I want to drive somewhere. I trust the auto manufacturer to create the proper level of abstraction for me. I know what HTML is supposed to look like, but I don’t want to remember exactly which attributes can be used for a dropdown list. What events are available to me and how that data is returned. If I can abstract that away, it is a good thing.

MVC promotes unit testing. It is designed as much as possible, to get out of the way and make testing simple. This is not the case with WebForms. In WebForms, it is possible to do testing, but it will take some effort. Is that enough to get you to give up some of the abstractions that WebForms provides? For me it is not. That may change in a couple years, but I suspect that instead what will happen is that MS will invest some time in addressing this issue in WebForms. The ASP.Net team learned a lot during the development of MVC and I know that they are already working on incorporating some of this knowledge back into the WebForms platform.

MVC will make you see how much you take for granted with WebForms. I recommend that everyone should live outside their home country for a little while. You will either learn to appreciate where you are from or you will find out that the grass is truly greener on the other side. In either case, you will come out ahead. I have had the privilege to have worked in many different development environments and programmed in many different languages. I appreciate the tools I have chosen because I have seen what else is available. I can articulate why I like VB over C# and why I like ASP.Net over J2EE. But I still think it is healthy to keep looking at alternatives. In the end it will make you a better coder.

So in summary, you really should checkout MVC. But not for the reasons Rob articulated. You should explore MVC because in the end you might just learn something that will make you a better web programmer, no matter what platform you choose.

f4518c38-c8dd-400e-91dc-939d48c5c20d|18|4.6

Tags: asp.net, mvc, webforms
Categories: Software Development
Actions: Permalink | comment

Comments (75) | RSS comment feed

Comment RSS | | Kick it! |

Three Things I thought I learned about Software in College Dare Obasanjo posted about Three Things I Learned About Software in College, which Scott Hanselman...security lessons learned Over the past couple of weeks, the DotNetNuke project has had to deal with a few different security...jQuery for ASP.Net DevelopersThis past year I had the pleasure of being asked by Jim Minatel at Wrox to write a Wrox Blox coverin...

Comments

April 23. 2009 10:48

Doesn't sound like you're still waiting for a good reason to try MVC - you listed several in your post. A proper title might be "Rob didn't list any GOOD reasons to try MVC, so here are mine" .

I think a desire to write maintainable code, using best practices for software development like automated testing, DRY, and SOLID principles are good reasons to investigate MVC. It makes it much easier to achieve these things, so that's my one reason I would add to your list.

Steve Smith

April 23. 2009 11:16

@Steve - Yeah. When I started the post, I really just had the top part roughed out in the comments on Rob's blog. I hadn't formulated my reasons until very late in the dev process when I thought it best not to start a flame war on my own blog ;)

jbrinkman

April 23. 2009 12:04

Trackback from PimpThisBlog.com

The Accidental Geek - I Spose I'll Just Say It: Still Waiting For a GOOD Reason to Learn MVC

PimpThisBlog.com

April 23. 2009 12:53

Thanks for the great article Joe. I need to read up more on MS MVC as MVC still harkens me back to my days of programming with Smalltalk in college (1993). I'm still think it's amusing that it's taken almost 40 years to finally catch up with concepts that were implemented in Smalltalk in 1970.

David O'Leary

April 23. 2009 15:01

You're a tricky one Joe...

A Red Herring is a deliberate dodge to change the subject of a debate. In the 7 reasons I listed, I don't think I ever tried to change the subject from "you should learn MVC". Ironically your post starts out fairly anti... then you change the subject...

A Straw Man argument means that I deliberately mis-stated an opposing opinion so I could argue with it. It would seem you're pretty familiar with this whole thing (being a Republican it must be second nature by now... so I can forgive...)

>>> "Another great use of straw man arguments and red herrings.  Come on really?  You are going to trot out jQuery as a reason to try MVC?  Why not say “Use MVC because it runs on Windows and works with IIS"

Now THAT, my friend, is a Straw Man! I'm not sure I said that people should try MVC because of jQuery did I? Why no, I didn't! Brilliant dodge there (hey - was that a Red Herring?) What I did say is there is power in changing your thinking to rely on client programming equally with server programming. Sure you can use jQuery with WebForms - but it's really FUGLY

>>> "Non-validating Html - Really, that is the best you have?  To paraphrase a quote from Rob - "Non-validating HTML is as Non-validating HTML does"."

The smoke must be thick in your room is all I can think. So you're taking two points, and smashing them into one - mangling my thoughts. 1 - Spaghetti code (the quote here) has to do with page scripting - not HTML. You may not care about your markup, but a lot of people do (including me).

>>> "Amazing, you can use IoC with MVC.  Wow"
Straw Man again - and well done I spose. The thing you've taken completely out of context here is my point - that you can swap out all parts of MVC - which I really like. I then used IoC as a reason I liked having my own Controller - not sure I ever said you couldn't do that with WebForms. What color would you like your Herring Mr. Brinkman?

>>>It will expose you to a different architecture.
>>>You will be forced to become intimately familiar with HTML and HTTP
>>>MVC promotes unit testing
>>>MVC will make you see how much you take for granted with WebForms

Great points! It's almost like one part of your brain actually understood what I was trying to say - the other part was saying "nah - I'll just a be a dick about it cause Rob loves it when I give him a hard time"

Rob Conery

April 23. 2009 15:28

+1 for Rob on this one. His comment sums it up.

Randy

April 23. 2009 16:00

Actually Rob, you use lots of misdirection and straw-men arguments in your post.  In many cases you do it by inference.  You give 7 reasons for giving MVC a try.  Lets take a look at one  "Control over HTML. I’m sure you’ve heard this before – mangled ID’s, non-validating HTML, etc"  In this reason you set up the false notion that you can't control IDs or get validating HTML in Web Forms.  And then you use this false notion as a reason for trying MVC.  You have all the control over your HTML as you wish without ever shifting to MVC.  You may need to give up using controls to get it, but then you have to give them up to use MVC anyway.  The difference is that in webforms I only give up the convenience when I absolutely need control, which is not for every single angle bracket and char sent to the browser.

The jQuery argument is equally misleading because once again you are using it as a reason to move off of Web Forms.  It is the whole context of your 7 reasons.  You don't have to explicitely say "Don't use Web Forms because..." in every point because you already said it when setting up the 7 reasons to try MVC.  You talk about client side JavaScript development (and I only pull out jQuery because I figure my readers are smart enough to extrapolate the thought to all the JavaScript frameworks mentioned).  You have setup a case for JavaScript and client-side development being fun, but have given no bridge to why MVC is any better at facilitating this than WebForms (see my point above about controlling your HTML).  Regarding your response here on jQuery+WebForms = FUGLY.  Clearly my friend you are doing something wrong in your code if that is the case.  I thoroughly enjoy working with jQuery in WebForms and changing frameworks doesn't make the client side code work any differently.

Re: IoC - Ok, there might be a few bits of hay still hanging off this one , but my point still stands.  The extensibility you tout in MVC is also available to people using WebForms.  For example, webforms provides the page lifecycle to give developers flexibility.  It may not be the type of flexibility you desire or it may not give you enough control, in which case ASP.Net lets you drop down and swap out the PageHandler to use one of your own creation.  So where is the lack of extensibility here?  The fact that every case of extensibility you pointed to, RouteHandler, View Engine, IoC are all available to WebForm developers.

There are many great reasons to try out MVC, however, WebForms having poor control over the markup, or having poor client script interaction or not having decent extensibility or not being fun or not being testable are not good reasons in my book.  All of those things are available in WebForms for anyone who cares to use them.  The fact that some people choose not to take advantage of those capabilities is not a knock against WebForms.

jbrinkman

April 23. 2009 17:25

IMHO you got the difference between WebForms and MVC exactly right in a single statement (no use in me arguing any of the details): "Every abstraction is about making tradeoffs".  Both have tradeoffs.  The only good reasons to use WebForms or MVC is in what things are important to you.  Both have their advantages.  Sometimes it's something you care about.  Sometimes it's not.

All I can say is that in my many years of using WebForms, I personally found that I was constantly fighting it to get the end result I wanted.  Now that I've switched to MVC it definitely is more work to do simple things but I don't have to bend it to my will.

I would personally never try to convince someone to switch to either, especially if they're happy where they are.  Both have advantages and disadvantages.

Erik Porter

April 23. 2009 18:18

@Erik - For me that is an important understanding. In my last job, my company was building a development tool where we prided ourselves on making the simple things trivial and the difficult things possible. I personally don't desire to move to a system that makes the simple things tedious. I want a system that abstracts out the simple stuff as much as possible, and when the abstractions get in my way, allows me to push them aside and get to the bare metal. From my perspective, I think WebForms does an admirable job of achieving that goal. Webforms is not right for everyone, but there are a very large number of developers who will be turned off by the amount of grunt work that MVC requires.

jbrinkman

April 23. 2009 18:23

You lost me at arguing that jQuery works well with WebForms.

So this is... elegant and easily maintainable?
$("#ctl00_HeaderContent_siteHeader_userMenu_loggedOff").slideUp();

And in your effort to 'prove red herrings and straw men' you've decended to what amounts to ad hominem attacks.

Michael K. Campbell

April 23. 2009 19:31

@Michael - I would never use that selector.  You could easily use:

$("div['id$=loggedOff']").slideUp();

If you don't like that, you could extend jQuery with:

jQuery.expr[':'].aspnet = function(elem, i, match) { return $(elem).filter('[id$='+ match[3] +']').length == 1; }

and then your selector would look like:

$("div:aspnet('loggedOff')").slideUp();

If you are still concerned about this syntax then you could use a marker class to identify the control and finally if you still are not happy you can follow my earlier suggestion and not use a control at all but just use straight HTML.  Webforms does not require you to use controls.  It is perfectly happy working with raw HTML.  You loose some of the benefits that WebForms provides, but when you really want raw control, you always have the option.  As you well know, development requires the coder to make tradeoffs.  Depending on the needs of my jQuery, I will make changes to my server side rendering code.  This is no different than the decision you make when implementing code in MVC.  You decide where to add IDs or Classes to make your jQuery and CSS easier.

As for the ad hominem attacks - not at all.  My comments to/about Rob were taken by him in the same vein in which I wrote them.  I was tweaking his nose a little.  Rob and I know each other well enough by now that I feel comfortable with my comments.  If Rob felt offended or thought they were personal attacks against him, then he is free to email me, IM me or even send me a DM on twitter and I would be happy to retract my comments.  Based on his comments here, and in twitter, I think he has a pretty good understanding of my intent.

The bottom line remains the same.  There are many good reasons to learn the MVC framework.  I just don't happen to believe that many of the reasons Rob listed are good ones and that much better and stronger reasons exist.

jbrinkman

April 24. 2009 00:20

Pingback from elegantcode.com

You Should Maybe Learn MVC For Good Reasons (if you want, maybe) | Elegant Code

elegantcode.com

April 24. 2009 00:37

Trackback from DotNetShoutout

I Spose I’ll Just Say It: Still Waiting For a GOOD Reason to Learn MVC - Joe Brinkman

DotNetShoutout

April 24. 2009 06:40

Damn... Why nobody cares should i learn how to use Dundas charts? :/

Anyway - raising popularity with such a blog posts won`t make anyone smarter. Replace those 'Should you learn something' posts with 'How to ... in ..." posts and everyone will be thankful.

Mr Anonymous

April 24. 2009 08:10

@Anonymous - "How To" posts definitely have their place, but if people are not motivated to learn a new technology, language etc. then the "How To" information is useless. They first need to understand why they should bother. If you give people a strong enough motivation, then they are willing to fight through problems to get to the end goal. If it is just a passing thought, then they will abandon the effort at the first challenge as they have no motivation for working through the issues.

jbrinkman

April 24. 2009 09:17

Personally i'm sick of HTML altogether (WebForms and MVC).

I'm focusing my efforts of Silverlight

kevinj

April 24. 2009 09:27

Pingback from alvinashcraft.com

Dew Drop - April 24, 2009 | Alvin Ashcraft's Morning Dew

alvinashcraft.com

April 24. 2009 10:18

One must motivate himself.

Mr Anonymous

April 24. 2009 10:39

++ on Kevinj's comment. Ultimately, if you really think about it, HTML was originally designed to be a document format for the internet. We have hodge podged, hacked, frame worked, abstracted, patched, updated, standardized, unstandarized, client scripted, server scripted, and plugin'ed it, but ultimately it is all a hack to build equivalent desktop applications as web applications. It works...but it is a pain, a joyous pain, but a pain never the less. We need a different way to go about things. Silverlight/Flash/Flex/Unity are steps in the right direction.

All in all great blog and good post. I like it when people challenge the conventional wisdom. MVC, as valuable as it is in some cases, is blowing around like fad right now. What's the next fad?

infocyde

April 24. 2009 11:55

@infocycle - I tend to agree with you on the abstraction bit. HTML and HTTP were not designed for building statefull applications but for serving documents. We have bastardized it from the original intent and then have arguments/discussions over which bastardization is better.

jbrinkman

April 24. 2009 13:04

is this a typo?

>> I can articulate why I like VB over C#

if not ... that would have saved me a lot of reading

cheers

mike

April 24. 2009 13:26

MVC = FEH

There may be reasons, but I have work to do. I don't want to spend a bunch of time playing with something is going to be ditched as a fad in 6 months. I am really at the point of overload on new MS initiatives, projects, technologies, etc. Aren't you glad at this point you didn't spend a month learning Windows WorkFlow (WF)? Well, I did spend that time and it was time wasted (again).

Jason Short

April 24. 2009 13:45

Nice Blog...

Jones

April 24. 2009 20:19

I agree with the points made by Erik Porter. WebForms & MVC each allow certain things to be done more easily, and other things not as easily as the other option. So it therefore comes down to which of those concerns matter most to a particular developer or team of developers. Most of the voices at Microsoft have been pretty careful not to characterize one as better overall than the other. However, becoming familiar enough with both to facilitate chosing the best option for a specific project sounds like a reasonable notion.

EricTN

April 25. 2009 10:24

Joe,

Your rebuttal of Rob Conery’s blog post makes me laugh. His case for learning MVC is jejune, and yet no commenter challenged the paucity of his argument. I laughed while reading reader comments because almost everybody praised Rob for another fantastic post. People are so enamored of Rob, the omniscient demigod, the superstar, they swallow his inanities lock, stock and barrel.

However, I’m switching to AspNet Mvc because --

1. I’ve never taken a liking to web forms. When I started programming in AspNet, web forms were touted to be extremely easy and conducive to high productivity. Au contraire, they are exceedingly complicated. By the time I’d learned how to use interesting features that you mention, but no book wrote about, my disgust became irrepressible.

2. Web forms are dead. They are as dead as VB6, windows forms or Visual Basic .Net. That is to say Microsoft will support web forms forever, but they have no bright future. New web-based projects will be developed mostly in AspNet Mvc.

If anybody is still waiting for a reason why he or she should learn AspNet Mvc, I submit my point 2.

foobar

April 25. 2009 11:23

I have been using asp.net since version 1.0 but recently started leraning mvc and I must sat it is a releuf. With webforms I always struggle to get the result I want. With so many similar events, specially grids that it end up taking longer to do small cutomizaton which should have been done quickly. Web form is a mess!
MVC may not be perfect but I feel like power and code speration is so good that my designer can work on his own with views and integration is smooth.
Why ruby on rails, php are popular and used by most successful websites? Because they have MVC framework libraries.

amir

April 25. 2009 19:31

Trackback from Nick Wang

转几个关于ASP.NET MVC的讨论（英文）

Nick Wang

April 25. 2009 23:37

ASP.NET MVC just might keep me from abandoning over a decade of work on the Microsoft web stack. And since Rob has helped pave the way for me with his work on MVC, Web.Commerce, and SubSonic, I happen to be one of those who unfairly lift him to that demigod status.
I especially appreciated the point in Rob's article that 'WebForms is a lie'; it feels great to no longer have to defend harsh techniques. Many, many thanks to the MVC team.

MarkD

April 26. 2009 04:00

>>> ... almost everybody praised Rob for another fantastic post. People are so enamored of Rob, the omniscient demigod, the superstar, they swallow his inanities lock, stock and barrel

Omnicient Demi-God! You hear that Joe! Hey wait... what does "jejune" mean? Paucity indeed...

Is this blog republican only? (notice the little "r"... you been demoted son...)

Rob Conery

April 26. 2009 07:53

Hey Rob, I hear the huffington post is looking for you. They really loved your article on "MVC - Change you can believe in" ;)

jbrinkman

April 27. 2009 07:49

Nice post...

Jones

April 27. 2009 18:23

Trackback from Chad Myers' Blog

To MVC or to WebForms?

Chad Myers' Blog

April 27. 2009 18:43

This witty banter is awesome... I say whoever programs a light saber in their abstraction of choice wins!

oh yea, go SubSonic!

Stuart Allen

April 27. 2009 18:51

CGI-over-.BAT-files supports jQuery too, so if you're doing checklist-style comparisons, make sure you check the "CGI over batch files" column. Batch files are also technically a view engine, so make sure they get a tick mark for this feature as well.

In your paragraph ranting about abstractions and how do we decide which ones are valid and which aren't--where you make MVC and WebForms sound like equally valid choices--if you substitute any reference to "WebForms" with "MS Access Data Pages," there's no change. The paragraph reveals its bias when you make this switch.

I think I need to swear off these kind of opinion articles, because they follow a similar pattern:

1) upvoted heavily on DotNetKicks

2) punchy, aggressive post title

3) immediate backpedaling in the post from the aggressive title (and sadly, which many commenters don't read)

4) Lots of comments, who usually miss the main point of the article. Aside: click here ( www.lhotka.net/.../...-48e7-8e32-1c16010272d9.aspx ) and search the page for "Don't think so" - read the comment, then click the guy's website. Then read the next 15 comments. Awesome.

5) further backpedaling in the comments (even fewer people read)

Hmm.

Peter

April 27. 2009 19:10

Dude.  I just had to stop half way through reading your post because you're shitting me already and I had to comment.

The single-handed most definitive reason to choose MVC is for the pattern. M-V-C.  Following a discipline, abstracted layering (Separation of concerns) and if you are going to say oh but I can abstract webforms before, this makes it a hell of a lot easier, and sure you can, but WHY WOULD YOU WANT TO?

I would NEVER do a web app in Web forms AGAIN.  One day you'll see this and realise what we were all bangin on about.

Now back to reading the article......

Graham

April 27. 2009 19:30

Yeah ok read it all, yes rocks in glass houses here.  Don't see a real argument really...

I'll play on the attack too....

Webforms suck ass, and as you pointed out (now from what I have learnt here today, I think that was a straw man..heh), mainly due to the control library forcing you into shit markup.  I personally prefer fine-grain control over my html, which MVC gives me.  You can say this is achievable with web forms if you weren't to use the controls, but then I might as well use MVC and receive all the other benefits?! plus MVC gives me this out of the box and escorts my strongly-typed data gracefully into my action parameters for processing, what about with webforms? Request[].... pfft

Oh, and another thing on MVC's side.  Bye bye bloated Viewstate.....  ('you can disable this', ok? but does webforms provide an easy way on EVERY control to re-feed back in selected options? no.)

Separation of concerns! View data stays in the view!! css, html, js etc... you know the other layers.  I understand any great programmer will be separating out into a 3-tier model anyway, but I believe it's a great pattern all programmers from novice to advanced can follow and not be something new and proprietary each time, which most custom arch designs are.  Supposing you found new employment and you are aware they use the MVC pattern you could fairly confidently jump into their project and follow the tiers knowing what to expect.  Again, this aids all skill levels.

LOL @ saying "well you should check out MVC" at the end, just to make sure you can remain neutral with both communities

Graham

April 27. 2009 19:34

@Peter - My intent when writing the post was that the reasons Rob gave for adopting MVC were not very compelling. Most of his arguments would apply equally well to so many different languages/frameworks, and in fact many of the arguments he uses to say you should learn MVC can be applied to WebForms. At the end of the post I presented what I think are better reasons to learn MVC. That is not backpedaling. That is providing what I think Rob should have said to begin with.

@Graham - I'm glad you like MVC. But your like/dislike of MVC doesn't really affect my choice of frameworks any more than all those C# developers affect my choice of VB as a programming language. Many don't agree with those choices, but those people don't pay my bills.

jbrinkman

April 27. 2009 20:01

Another reason not to go 100% full steam with ASP.NET MVC for me are two things. It is a 1.0 release and its going to get better in ASP.NET 4.0. .NET 4.0 is not too far away.
For modular applications that require Web Parts and/or portal functionality you need the ASP.NET Web forms postback model. Hopefully, SharePoint 2010 helps us out with ASP.NET MVC Web Parts?

Bart Czernicki

April 27. 2009 20:05

@Graham - WCSF - disable viewstate and use jQuery and controls, etc.
    IMHO - gives me the best of all worlds - testability, seperation of concerns, n-tier out of the box, etc.

------------

People associate WebForms with viewstate and bad HTML... it is ONLY the controls they use that cause this bloated messy crap.  What you will see for the forseeable future in MVC is umpteen "controls" that are proprietary "versions" of webforms controls!  If, today, you start with an MVC app, by time you are done coding your LOB APPLICATION, you will have basically hand coded all the necessary functions of webforms yourself...

yeah... how fun.

Learn webforms, DEEPLY and you would do as well as learning MVC DEEPLY.  Learn either of them at a level no deeper than the out-of-box experience and they will both be equally "bad".  If you have bad markup using webforms - then you DO NOT KNOW HOW TO CODE WEBFORMS with any level of expertise.

There are a multitude of levels of programmers out there though.  I always tell my clients - if you are moving from classic ASP or VB6, then C# it is(I've found that this easily breaks many bad habits) otherwise, if you are learning .Net as your first foray into MS languages - CHOOSE which syntax you like.

Webforms is not dead, yet... MVC will not be the one to kill it though - Silverlight will.  IMO

Tim F

April 27. 2009 20:08

@Graham - You should ghost write Rob's blog posts. You have much better arguments, although tweaking Rob's nose is much more fun ;).

jbrinkman

April 27. 2009 21:07

Posts like this always floor me, he he he. Does it matter why or why not you should learn MVC?

You should learn it because it's something new and different and because change is good. The same reason I learned some Rails. I don't need any other arguments then that.

Boyan Kostadinov

April 27. 2009 21:09

Our new MVC app, bugs deployed to production after upgrades, including syntax errors in the views!? My preference is WebForms, Ctrl+Alt+B.

Valamas

April 27. 2009 22:00

used webforms since it was called asp++ next generation, it was pretty cool to play with, the webform framework could be used and designed just like MVC, but then again where do you get that support from? You have to either implement that youself or go with RoR or the like, which is ok, but in my case i wasn't exposed to any of those 3-rd party ones ... was really blown away when microsoft's asp.net mvc came out. Anyways, there is a place for both frameworks webforms and mvc, all comes down to what one is more comfortable to work with.

asp.net mvc rocks!

mike123

April 27. 2009 22:43

For me the fact you have to resort to slow selectors like $("div['id$=loggedOff']") speaks volumes for why the move to mvc is needed!!

redsquare

April 27. 2009 23:05

@Redsquare - go back and read my response again. You don't HAVE to resort to that selector. It is a choice. You can have clean IDs if you wish, but there is a tradeoff. Moving to MVC requires that exact same tradeoff. The difference is, in webforms you at least have a choice as to whether to use a control for any specific piece of functionality or not. With MVC there is no choice - but then you have other benefits.

In addition, the "speed" or lack thereof for this particular selector is relatively trivial. Like Rob's initial arguments, this performance argument is also a Strawman - performance is always relative and case specific and this argument is mostly used by people as a sort of boogeyman to scare programmers into doing things a certain way. Choosing MVC for this reason is just one more case of premature optimization.

jbrinkman

April 27. 2009 23:32

The reason to go MVC is simple, WebForms don't work for non trivial applications. They are an impressive effort to abstract away the internet, dont get me wrong. They will take you 80% of the way lightening fast (as long as you give up caring about your markup), but that last 20% is a doozy.

In that last 20% you actually need to know things about how the web really works, and use that knowledge to work around the way webforms is failing. In that last 20% you need to know the guts of how webforms works, to figure out why the seemingly simple thing you are trying to do is not working the way you intended. That last 20% is where you start sacrificing things like performance, scalability, and esthetic just to meet the business requirement.

If webforms successfully abstracted the internet away, I would think you had a leg to stand on. MVC embraces the way works instead of trying to hide it, and is rediculesly simple where webforms is mindblowingly complex.

Matt Briggs

April 27. 2009 23:52

You mean "I suppose" and not "I spose"

April 28. 2009 02:56

@Joe
"If they were afraid to use jQuery before, they won’t use it just because they are in MVC. If they didn’t care about testing or HTML or clean URLs, MVC is not going to make them see the light."

This is exactly what happened to me, as a matter of fact
Everything is so clean and tidy and separated in MVC, that navigating large projects is a walk in the park. Maybe I could blame this on my ignorance when creating web-forms apps earlier, but The Truth is, I'm never going back to web-forms if I have the chance.

Now, I've read both yours and Robs posts, and what I would really like to see now, is some blog-post with the heading "This is why you should use ASP.NET Web-Forms, and stay clear of MVC"

I'm gonna dare to say that 80% of people going over to MVC will actually care more about their HTML markup (validation and so forth), because it's EASIER to have full control. Not saying this is impossible in web-forms, but no matter how nice it looks in the beginning, I always give up struggeling with html-markup. It's quite a joy running a pretty heavy MVC-app through the W3C validator, and seeing it pass

Thanks,
Yngve

Yngve

April 28. 2009 03:49

I would never use that selector. You could easily use:

$("div['id$=loggedOff']").slideUp();

Surely that breaks things? I was under the impression that ASP.NET has long ugly ID's because you can build pages from different parts and this ensures their ID's don't clash. This means there is potential for your selector to fall flat on it's face. Or even if I have 2 id's that end with loggedOff (notloggedOff, isLoggedOff - or something like that)? Plus in terms of selector performace selecting by ID and selecting using ID ends with selecting by ID is far more performant.

James.

James Hughes

April 28. 2009 05:16

I find it laughable so many of the MVC folks are bagging on WebForms.

Especially the abstraction point is so freaking ridiculous. C'mon MVC with routing and Model, Views, Controllers and CODING BY CONVENTION is not abstraction? WTF? That's the lamest thing I've ever heard.

jQuery/client side code hard in WebForms? Huh? I can think of at least 5 different ways of doing this in Web Forms with very little code and NO SPECIAL SETUP. In fact if you use services how the hell is that code going to be any different at all between WebForms and MVC?

And lets not forget the most obvious point, if you want to keep things simple (ie. just write markup with embedded script) you can do that with Web Forms too. If you want to keep things REALLY simple (like in DUMBED down like MVC ASPX views) stick with code in OnLoad() and render with <%= %>. How is that any heavier than MVC?

I've code WebForms for years in a fairly light weight manner because along the way I never forgot about how we used to work prior to ASP.NET and understand what WebForms does with its abstraction. This means ViewState off in most cases. Means not always posting back but linking manually, using Repeaters/ListViews instead of grids etc. etc. It doesn't take a rocket scientist to figure out what's efficient and what isn't and by extension what features to use and which to skip (ie. bloated controls). Somebody who doesn't understand HTTP/HTML will write shitty Web applications on any platform.

The only argument for MVC that really holds any water is unit testing ability. And that's a valid one for sure if that's what you're after.

I don't have a problem with MVC. I've been (slowly and silently) checking it out. I like some of it, hate other parts, it ain't all sun and roses. MVC has its foul parts just as Web Forms does.

What does bug me is the freaking snooty and holier than thou attitude of the self proclaimed 'evangelists'. One look at the comments here tell that story. Get a life folks, Web platform isn't a religion.

Rick Strahl

April 28. 2009 06:17

I feel MVC is a step back and complicates developing Web pages. I do believe the framework was developed keeping in mind Unit Testing ability, but the same can be build into regular web form application by using an intermediate service layer for each page and wrapping certain http redirect operations.

Sachin Bhatt

April 28. 2009 07:16

For me the only needed reason to develop with MS MVC instead of webforms, is because it´s just a whole lot easier. For me, building a mvc app with great structure takes a lot less time and effort then doing the same with webforms. Ofcourse you can do the same things with webforms as you can with mvc and the other way around, it´s still web development with the same ground rules, but I use alot more "workarounds" while developing a webforms app then I do when I use MVC.

Ofcourse everyone can´t feel the same way. But I think everyone should have tried both before "chosing side".

Mattias Jakobsson

April 28. 2009 08:09

@Mattias - The problem with too many programmers is that they feel they need to "choose sides". That is like arguing which is better a hammer or a screw driver. They are tools. I pick the one I think is most appropriate for my current task. The criteria for what is most appropriate will sometimes include my comfort level and expertise with a particular tool. I would never presume to tell a woodworker who is an expert with a hand plane that they are wrong and should use a power planer instead.

jbrinkman

April 28. 2009 08:42

Arguing over webforms and MVC is like arguing over VB and C# - they both provide the same things but deep down we all know C# is better

Rob Lad

April 28. 2009 08:45

I'm in the "tool for the job" camp. I'm excited about what MVC has brought to the table for .NET developers, not only because their are certain aspects of Webforms that I don't like.

Ultimately, I still feel that both have their place and there are aspects of both that I like. This may mean I'm in the sitting on the fence camp too, but I don't see what any personal attacks on opinions will achieve?

Ryan Tomlinson

April 28. 2009 14:55

@Redsquare - go back and read my response again. You don't HAVE to resort to that selector. It is a choice. You can have clean IDs if you wish, but there is a tradeoff.

Why would I want to battle and accept trade off's just to achieve workable id's for elements? I have walked into roles where they were throwing an extra 20k down the wire simply because they had repeaters inside user controls inside content placeholders etc etc not to mention the badly written js for the validation / ms ajax functionality. I have done my time battling with webforms and the mess that it can create. Enough stupid and lengthy workarounds to try and keep hold of a valid dom. It takes the fun out of the web. Also calm down. It was not a personal attack.

redsquare

April 28. 2009 15:15

@Redsquare - I'm Quite calm here. Just responding to your comment saying you "have" to use a certain selector. I have done plenty of jQuery without all the headaches you describe as have Rick Strahl and Dave Ward and tons of others using jQuery and Webforms. Creating badly mangled IDs in areas where clean IDs are important is a design decision. It does not have to be that way. It ends up being that way for many webform developers because they don't know any better. That is not a webform problem, it is a developer problem.

jbrinkman

April 28. 2009 15:55

Finally a healthy and neccessary post about MVC! I totally agree with the points beeing made in this post. Personally I will wait a bit before I put MVC on a new project. Testing it out gave me some really clear flashbacks from when webforms was new: trying different ways to get a specific thing done - no best practice yet, seeking solutions to problems which just should be easily solved...

Kim T

April 28. 2009 16:21

@jbrinkman I dont agree but I can only admire your resistance, Nelson would be proud. I would actually like you to post some url's that you have written using webforms that produce a well formed & validated dom and offer an unobtrusive experience. I have not seen one as yet, here's hoping you can change that.

redsquare

April 28. 2009 16:46

@redsquare - Exactly what part of writing HTML did you not understand? Are you having problems creating html elements with your own IDs? Seems to me you can add <div id='myid'>some content</div> in your aspx/ascx and have it render correctly every time. In fact if you look at my jQuery tabs post from a couple months ago (blog.theaccidentalgeek.com/.../...-DotNetNuke.aspx you can see exactly what I'm talking about. You don't need to use web controls to achieve rich functionality, especially if you are relying on jQuery. Tabs, Grids and many other traditional server controls can be replaced with jQuery and therefore don't require the use of heavy server controls.

jbrinkman

April 28. 2009 18:25

jbrinkman - no live links then? I dont really fancy installing dnn et al.

redsquare

April 28. 2009 18:52

@redsquare - I don't build websites in general. My full-time job is working on DotNetNuke, and the portions where jQuery is used is primarily in Admin areas, since there really is very little public facing portion of DotNetNuke. The only other place I use jQuery is in sample apps for conference talks. Much of those are ad-hoc jQuery built during the session. But the basic principle remains the same. jQuery is much like CSS. You identify where you want to hook into the html and you craft your html to allow that. With jQuery, I will provide ID hooks if needed, but often class and tag-names are also sufficient. I don't require every ID on the page to be handcrafted since I don't write jQuery or CSS against each ID. I use hand-crafted IDs where needed and use server controls for ease of use where desired. Also because I am not trying to recreate Silverlight with jQuery scripts, I do not worry too much about perf unless it becomes problematic.

jbrinkman

April 28. 2009 19:54

@jbrinkman lol thanks dude. I was high on coffee when I wrote that, glad it was semi-coherent

Graham

April 29. 2009 10:26

After reading your article, I think you have used an inaccurate title.  I believe your title should say "...For a GOOD reason to *USE* MVC"

It's clear you've *learned* some MVC because you list your interpretation of reasons to learn it...which implies you have done so.

I believe as a developer, one should be motivated to learn what's out there, whether it's MVC, IoC, IronPython, etc...doesn't really matter.  In order to have the right tool for a task, you need to know what different tools do for you (increase/decrease level of abstraction, etc.)

SanjayU

April 29. 2009 11:32

Trackback from Craig Shoemaker

Exploring ASP.NET MVC 1.0

Craig Shoemaker

April 30. 2009 18:07

Good post!

Software development is a lot like the fashion industry. When something new comes along, many people just have to have it and the latest is always the greatest. People relentlessly trash what is old ("classic") and call anyone who doesn't share their passion for the latest thing an idiot and incompetent.

I prefer to wait. If MVC is so wonderful, it will stand the test of time and become the best way to develop asp.net applications. (Of course something newer will eventually come along and the same people will trash MVC, etc. etc.) But I don't care about the latest thing. Otherwise I would be switching programming languages and environments constantly. Sometimes, the best software development environment is the one you understand and feel comfortable with.

Paul Hyman

May 7. 2009 08:19

Brinkman,

> $("div['id$=loggedOff']").slideUp();

Where do you get off?

That's a hack that says match the end of the ID string instead of matching the whole ID in hopes of making code look pretty.

Clearly you don't understand that IDs are meant to be unique. If you have two ID's ending in loggedOff this code breaks and defeats the whole purpose of using IDs in the first place.

That's good enough reason for me to believe you are not qualified to speak about good HTML, let alone take credence in whatever else you might have to say.

aleemb

May 7. 2009 08:39

@aleemb - I always love ad hominem attacks as it speaks volumes about the commenter. Rather than make assumptions about your own lack of knowledge on the matter, I'll just assume you overlooked the possibility to add an ID higher in the DOM tree or to use the element type or a class or any of a dozen different techniques to guarantee uniqueness in the selector. I also give you the benefit of the doubt and assume you completely missed the rest of the comment where I give other perfectly valid methods to achieve the desired behavior. So instead of attacking my qualifications, maybe you should just read what I actually wrote and not pull items out of context.

jbrinkman

May 7. 2009 12:12

Brinkman,

First you propose tackling this:
> $("#ctl00_HeaderContent_siteHeader_userMenu_loggedOff").slideUp();

with your unreliable solution--yes it is unreliable because it doesn't guarantee it will resolve to the intended node. And yes you did propose it as a solution as anyone can scroll up and see.

When that came under fire you're trying desperately to redeem yourself by proposing that this:

> $("#ctl00_HeaderContent_siteHeader_userMenu_loggedOff").slideUp();

instead be tackled by doing extra lookups for cushioning. So now we should select the parent ID which may or may not be possible (If not possible then wrap it in a div and assign that an ID). Then use selectors to find the child ID by doing a patter match against the last end of the ID. All that just to avoid:

> $("#ctl00_HeaderContent_siteHeader_userMenu_loggedOff").slideUp();

Even then it's unreliable. So let's keep trying lookups until it works. And then hope that another developer doesn't come and add another node under the parent node which also ends in "loggedOff". Great insight!

Don't kid yourself and eat some humble pie.

aleemb

May 7. 2009 14:24

@Aleemb - Great selective reading on your part. I guess I need to spell things out so people like you will understand. You do not have to use controls. If you are so worried about uniqueness, just generate plain HTML. If you read the post and my comments you will see that I posted multiple methods to achieve the desired result. I expect you to be smart enough to figure out when each one is appropriate and to understand the tradeoffs involved. In any case, I wish you success with MVC. Leave webforms for people who don't have such problems with the basics.

jbrinkman

May 13. 2009 05:38

Pingback from blog.adsystems.com.br

ADSystems » Os desenvolvedores ASP.NET devem aprender ASP.NET MVC?

blog.adsystems.com.br

May 14. 2009 11:54

I guess I'm older than most folks in dev these days because I remember pre .Net. All this MVC stuff looks a lot like how we used to write pages back before Server Controls and postbacks. And the folks I've worked with were never happy with those. On the other hand, we used them a lot and for good reason. "Learning a language" is not a good enough reason to use a technology. My job is to facilitate the business. To streamline, and improve business process. To connect people to information and boost efficiency and profitability. "Control over HTML" is about as relevant as a bucket of sardines. On the upside, client side javascript is better supported these days. So I suppose you can go out and set up your libraries to help handle all of that HTML you have to control now. As for testing. The kind of testing most places I have worked need is 1-2 folks with a keyboard and a few hours. Automated testing of any kind is clever and useful but it doesn't cover the gaping hole. MVC is meh. It is not revolutionary, it is not special, and it is not particularly bad. But it is a trade off and smart dev teams will standardize on what makes money. Not on what is new and/or clever.

Programmer2

May 15. 2009 04:04

Some of the posts say that using ASP.NET MVC makes it easier to test. It is the same with WebForms if used appropriatley it is also testable.
For exaample one ca use the MVP pattern, see the following link:

msdn.microsoft.com/en-us/magazine/cc188690.aspx

At least if one uses MVP pattern one can mock view and test it.

Cheers
Yaz

Yazid

June 12. 2009 19:54