Everyone who talks about ASP.NET MVC gets asked the question:
Should I use MVC or Web Forms?
There’s been quite a bit of debate on this topic, but in a couple years I don’t think it will matter.
… those who can count in binary, and those who don’t care.
The IT developer who doesn’t read blogs and works 8 hours a day in a Microsoft shop is either portrayed as a hero who produces business value, or vilified as a duct-taping Mortimer who produces a mess. The truth is somewhere in the middle, and the fact is that these developers look at MVC and Web Forms and see this:
… which is why so many people ask the question. There is no clear distinction. Most developers don’t have a passion for TDD or composite UIs – they just want to get the day’s batch transactions through the firewall and into a spreadsheet for the business folks. “I see two web frameworks. I can use either. Just tell me which one is best!!”.
Meanwhile…
There was a big SharePoint conference last week, and SharePoint is clearly positioning itself for global feature domination.
When you stack up SharePoint versus MVC or Web Forms, then everyone can see a contrast. One is a small framework to build on. The other is a giant platform that moves tons of data across the corporate landscape.
The SharePoint platform is an out-of-the-box-do-everything solution you tweak and augment for a particular environment. Some developers think this is great. Some developers think this is scary. At least the contrast makes for an easy decisions.
… those who like frameworks, and those who like platforms.
Developers who like platforms will want to use SharePoint. Install it. Customize it. Then watch end users collaborate in spreadsheets on numbers from Analysis Services.
Developers who like frameworks will want to use MVC. It’s light. It’s extensible. It leaves them in complete control.
Web Forms is caught in the middle. The abstraction is too heavy for framework lovers. At the same time, it’s not an out-of-the-box solution despite all the drag-n-drop data controls and pre-configured providers. It’s vulnerable to both sides and both SharePoint and MVC have momentum and excitement.
The question in the next decade won’t be: “MVC or Web Forms?”.
The question will be: “MVC or SharePoint?”
But nobody will ask the question, because the answer is easier to figure out.
Subscribe
Twitter
Search
About
Comments
-- Scott, are you saying ASP.Net Webforms is moot?
Web Forms + Ajax is a perfect fit for the many small to medium commercial web applications that we develop whereas sharepoint is either overkill or the client has committed to another cms.
I have no issue with mvc (its "back to the future" using techniques from the asp pre .net days) but i suspect its attractiveness to a lot of developers is that they can avoid the learning curve associated with web forms.
I truly hate Webforms. They give me crappy control of the output code (1998-style HTML), it's difficult to handle once you're doing something that's just plain basic in the framework. And the fact that you must wrap your entire page in a form-tag and always have that viewstate there. It's dreadful if you're into web standards and all that. And I am.
WebForms simply abstracts away too much of what makes web development different from desktop development. You're supposed to know stuff about how to send and get data, how to store data across pages etc. It's just plain messy. In my opinion, WebForms is a true Web 1.0-way of thinking development due to all the silly restrictions all those opportinities give you.
This is what makes ASP.NET MVC so great: You have *complete* control of all output code, it's easy to do testing because you are the one that's always in control of all code (no gridviews or fileupload-controls here!). It's made up the way a web framework is supposed to work, it doesn't abstract away everything with an enormous ViewState to control the flow of your pages.
More to the point of the article, I completely agree with Scott's take on the matter. In fact I'm already seeing this happening as I hire new employees and consultants - there is already a large swing toward SharePoint development amongst the WebForms community.
I'm agree. I think it's time to let go WebForms and focus on MVC. WebForms was thought so the VB6 developers can use the .Net Framework to develop Web apps without to have to learn or get used to a new environment...
But, it's just my opinion.
But, developing for it is fundamentally different from MVC and WebForms, so the assumption that people will take whatever they were going to develop in WebForms and now develop that in SharePoint, is too simplistic a statement. Today, if they were to attempt to build what would be a typical WebForms app in SharePoint, they'd probably still have to create a database, because SharePoint's lists have too many limitations. Then, because they aren't using SharePoint's lists, they'd have to create CRUD pages on top of the database tables, and then manually work up validation, business logic (can't use Workflow anymore), and so on...and so they'd be developing a WebForms app inside SharePoint. In the future (SP 2010) maybe enough of the typical LOB app's needs will be covered by the platform, and so developers will be able to use the platform exclusively. Don't know/we'll see.
I guess the point I'm making, is that you embed an assumption above in your dichotomy(? big word alert)--you have developers who like frameworks and developers who like platforms. The assumption is that frameworks and platforms are roughly equally good choices at getting the job done. What I'm saying is that developers who like platforms, in order to solve real problems, have to learn both the platform (SharePoint) and the framework (ASP.NET), and would be better off just learning to be effective with the framework and skipping the platform. There's a small sweet spot where the platform does exactly what you need and saves you time, but I'm going to invoke my very own Pedro's Improved Pareto principle, in which I replace the 80/20 rule with 8/2. 8% of what you need is done with 2% of the effort, the other 92% is left as an exercise for the reader.
I guess this makes me a developer who likes frameworks.
I feel like this is one of the most common misconceptions about SharePoint...
"Anything else you can think of? Check."
It is a fallacy to assume that SharePoint is the all encompassing solution that makes standard ASP.NET technologies obsolete. SharePoint is an amazing platform the transcends any standard definition like "Intranet" or "Workflow" or "Business Intelligence". It is all of these things and so much more.
However, as a previous poster pointed out, it is most certainly not an operating system. I don't really think that the words "SharePoint" belong in a comparison between WebForms and MVC.
As to the question of which ASP.NET framework is better, I really think that the fundamental advantage of MVC is the ability to properly do test driven development given the decoupling of the UI from the other layers. WebForms are nearly impossible to test in an automated fashion. I really think that it is high time for Microsoft developers to enter the world of "best practices" when it comes to ASP.NET as a web technology. Whether or not MVC is the proper platfrom is less of a question as simply saying that WeForms is no longer an option as it makes writing flexible and maintainable code very very difficult.
I really really hope this post isn't overly harsh, but I feel like it might be. I know I am going to regret hitting the "Comment" button here in a few seconds.
Thank you for this post. I feel like it has brought out some excellent thoughts on ASP.NET and SharePoint.
+-----------+-------------+------------+------------+
Simple Complex Too complex WTF? $$$$$$!!!
I think the real question for an MS dev is WebForms vs. MVC vs. Silverlight. If at all possible, I vote for silverlight. Javascript is powerful and all, but I just don't think the cleanness and productivity of having C# everywhere combined with a UI rendering engine that is easy to use and looks the same on all browsers can be beat.
@Brad - People are already creating Internet sites with SharePoint. In 2010 they explicitly market and license it for use on public facing web sites!
And you are an excellent writer: you need to write some books.
We implemented SharePoint two years ago and we absolutely hate it. The mechanics of configuration are miserable and the html that it emits is a train wreck. Forget adapting any feature in a web part the requires precise alteration of the DOM or html as the improper of tables prevent you from applying selectors effectively. Simple things like rounded corners with CSS is just not possible.
We also fought the dreaded IE 7 error where processing of the DOM would be interrupted and you get the cryptic message box "process interrupted".
It is a shame, as Microsoft could provide something that would be really great, but they have ignored html and css standards with MOSS 2007. If the thought process is that you can empower a team of web developers because of the consolidation of technologies, it fails as the implementation of solutions that are straight forward with Ajax and web services takes far longer in SharePoint.
However, I have a bit of a limitation that holds me back with WebForms and I was wondering if you could help me with it.
I work for a Web CMS company as a Consultant, therefore all websites (public sites, intranets, extranets, you name it) are based on the CMS software from my company (which should remain nameless).
One of the features that the sales guys like to pitch about our software is its "friendly" urls. Baiscally all data is stored and structured within the CMS like a file system. Then when you point your browser to http://mywebsite.com/about the CMS will return the contents from the item stored under the root with the name "about".
Each item also has a (interchangeable) template registration which is the physical location of the file that is going to display the contents of it (an .aspx page). Just like the "Views" on MVC.
So, to handle the friendly URLs I have to add a HTTP Handler as follows:
<add verb="*" path="*" type="Cms.ASPDelivery.HttpRequestHandlerFactory, CmsDelivery" />
That will take care of the friendly URLs and will do the mapping between contents and views.
In an architectural way you could see that just like MVC. The data is stored in the CMS, the presentation is independent of the data, and the handler will be the Controller.
But when it comes down to coding in itself, it is the same old Webforms spagetti. Do you see any way that I could use both MVC and my CMS' Http Handler?
It doesn't sound like you'd be able to rip out the CMS and place your own controller in place, but I'm not clear on the exact architecture of the CMS.
Since the CMS is basically delivering a model to the .aspx page, I'm wondering if you could write your page like an MVC view. That is to avoid code-behind and server controls and use HTML helpers and jQuery instead.
Ever heard of the MVP pattern?
Web Software Factory by MS patterns & practices?
n-tier/n-layer design...
Just because you dont know how to extend and use webforms corrrectly doesnt make it a bad platform.
The only benefit is see of asp.net MVC is if you want more control over mark up.
Which for me i dont care for anymore, after 12 years in the webspace im bored with html, Silverlight is where im moving too.. again making webforms vs MVC a dead argument.
The bottom line is it all depends on your needs.
The bottom line is it all depends on your needs.
If MVC truly was the wave of the future, wouldn't it be in Microsoft's best interest to phase out Webforms and get Webform developers up to speed on MVC? And isn't Sharepoint built on Webforms?
As it stands now, it just seems this whole Webforms/MVC/Sharepoint debate is all about religion. Or politics. Change the names to Democrat, Republican and Independent and you've got the same kinds of arguments, with each party not hearing what the other is saying.
IMHO, each advocate of the above has legitimate reasons to support their preferred platform/framework.