How to show benefits of adopting asp.net mvc to client?
I mean - we as developers can understand benefits of easier implementation of automated testing, better control over rendered html etc., but what would be strongest motives for client to accept usage of asp.net mvc?
Maybe there's some more nice looking examples built with asp.net mvc (excluding stackoverflow) to show?
p.s. Please, do not start flame war.
In this case - it doesn't matter if asp.net mvc is better than x or vica versa.
This question might be a little subjective, but I will take a crack at it anyway.
--Background:
MVC was picked for me before I started at my present company and I was charged with learning it, which suited me fine as I am very HTML oriented. The project is in development but we have iterative meetings to show progress and flesh out requirements. In one of these meetings I found a major payoff:
--My Experience:
The question of whether the site could support mobile phone access was put forth but up until now I had been designing the site for a 1024 x 768 minimum resolution. No worries, I simply turned off CSS Styles and the page displayed in a not-very-pretty-but-very-functional flow. The entire site is designed semantically making it easier to port to different front ends via style sheets and maybe a little JS. ASP.net MVC is awesome for semantic websites, which are cheaper and easier to maintain.
--More Stuff
This is one of several benefits of adopting a web technology that more fully embraces the medium it runs on. Others include:
Better separation of model view and control logic, because well its MVC, but this makes you code more loosely coupled, and more single-responsibility-principle adherent ultimately making it cheaper to maintain
More standards based, meaning its easier to use JQuery and CSS tricks that all the cool kids are using, because those really shine in well formed sematics-based documents. This means its cheaper to add flair
Restful, URL - driven requests. Your URL does not specify some .aspx to load and do a ton of work across a bunch of layers in its poor little code-behind. Your URL specifies a request which causes the router to invoke model-layer functionality which runs where it is supposed to, then dumps pertinent data to a view. Lots of good stuff here:
This makes it easier for one controller to serve up pages, webservices, AJAX, and handle all CRUD cases, but all around a single context.
Each responsibility is handled by a method called from the router, each group of related responsibilities can be materialized into a controller.
You control what data goes where, you can custom build a view model to go out to the view, and the view simply contains logic to show it, making things simple and secure especially if the people working oon the view are not the people working on the controller logic.
There's a lot more but in the time I have taken to type this, all the other answers have probably been posted.
Clients typically don't care what technology is used in building their website, so I would use cost as the driving factor for using ASP.NET MVC. Let the client know that their cost will ultimately be lower if they choose technology X (even if that isn't necessarily true). The bottom line is a powerful negotiating tool.
For the most part clients don't care about what is going on under the hood so long as it is
cheap
reliable
maintainable
compatible with anything they currently have
Cheap is easy to sell, ASP.net MVC is free. Reliable? It is built by Microsoft and that is an easy sell to most PHBs. Maintainable? This is a bit trickier since it is a new technology and there aren't a whole lot of experts. However the selling point here is that it is much closer to pure HTML than, say, webforms so should be easy for almost any developer to maintain.
Compatible is harder, but you can use user controls in MVC if that is what they have. This one you'll kind of have to solve for yourself as it is client specific.
This is a layered question:
Why use .NET - capability and performance (and there's no harm in saying its a technology you're comfortable with). IIS7 is turning into an very impressive platform.
Why use ASP.NET MVC? The key sell to a client here is the level of control you have over the output - this is a tradeoff you decide to take on board as a developer, you have more control so in some respects you have more work to do however the win for a client is in the resulting pages which should be smaller, more standards compliant, more search engine friendly and generally all the things that a public web site should be.
But if its for an internal site you have to actually make a more considered judgement, forms works, you can produce very good results and if you know the environment its going to be deployed into you may find that you're more productive with the building blocks it provides than with MVC.
As an aside, there's nothing to stop you using the strengths of the MVC model in web forms - the fault we tend to be most guilty of is failing to separate the logic correctly because its too easy not to, but from a clean slate you can be aggressive in what you allow.
I'd go the other route, find some crappy ASP.NET Web Forms sites to show them. Should be pretty easy. :)
Related
I am trying to explain why it's important to use MVC views over Form views within an MVC application. Some of the developers "expedite" work completion by adding form.aspx to the MVC project, technically using MVC but completely avoiding it. I think this is wrong because there isn't a way I know of to do the following things:
Have a route target an older aspx form
Have a controller assemble a model and send it to an older aspx form
Is it wrong to expect the same productivity rate from MVC over older aspx forms?
I would think that a developer that knows both ways of development very well, that the time to create the same solution would be the same (or better) with Asp.net MVC.
Background: We develop website applications used by corporate entities to maintain weekly published data, which could be "yet another customer control panel" to add or change software features about once a month (for each customer, lots of customers, lots of applications, extremely similar patterns).
The time to create an MVC site correctly is in my opinion and experience always going to exceed the time it takes to create one incorrectly. The time advantage to using MVC correctly (or any design pattern for that matter) is not always seen in the initial implementation, it's in the maintainability of the project, whether by the original developer or those who follow. Following good programming practices will result in long term time savings.
In terms of whether a pure MVC project is faster then a pure ASP.net project in terms of time to implement, it seems to me that the expectation could go either way, based on the developers experience, and on the applicability of the project itself to that framework.
I have personally found that for a sizable application that needs much of the 'plumbing' that an MVC app will demand anyway, I am at least as productive with MVC than WebForms.
But there is a learning curve, and a temptation for some 'simple page' to want to just 'throw up' a quick WebForm and be done with it.
I think the biggest gain with MVC, though, is in maintaining the application over time. It should be obvious how much easier it will be to do so with a strict MVC app, than a WebForms one. And adding WebForms into a 'mix' like that just, IMO, makes things even more difficult.
Once you are familiar with the MVC way of development, Its really very useful, scalable & lightweight.
Only initially it takes more time for development compared to Web Forms.
But advantages out number the Web Forms.
Just one of its example:
Its best suited for high traffic sites. In web forms control retains there states, we have view state and all.. During the page post back the whole data is sent back and results retrieved (High load on server). Whereas in Asp.Net MVC the controls are stateless. While posting back the Load on server is less.
like this has many more advantages..
And as it is based on Design Pattern its always good for starters. Who does not have much experience in Developing Applications previously.
With WebForms you can get away with using pre-canned solutions for a lot of things (grids, etc.). With MVC you have to roll your own or use a pre-canned javascript solution which can end up taking more time when compared to WebForms.
So to answer your question: it depends
Simple as it is :
Why to move to Asp.NET MVC & why not to move ( if there is any reason ) ?
Added
Is it a necessity to move ?
Can we say the future belongs to asp.net mvc ?
How many years do you think it can stays on top ?
MVC is much more well constructed, allowes for much better code seperation and control over markup, and is much lighter on the server, that IMHO the only reason not to move is if you have a legacy .NET application (or other) that is working flawlessly, and you're not expected to perform serious adjustments / fixes on it in the near future.
If you do decide to move, you should know that you'll be able to reuse very little of your webforms GUI and user controls, since MVS is built a bit differently. You class libraries you could reuse, if they're written well. In any case, writing stuff in MVC is much faster than in WebForms, even if done from scratch.
also looking at moving at the moment.
the main bonus for me is the complete control over layout. i'm also looking into implementing a restful API which the MVC model works very nicely with because of the path structure.
Josh
If we move for MVC we can add or edit any module so easyly.
So we can add any new module just like a plugin
I patrially disagree with the accepted answer. I have built large applications in both WebForms and MVC and here is my opinion:
ASP.Net Web Forms and ASP.Net MVC are both great frameworks that allow the C#/VB Net developer to build enterprise level applications. Choosing which one to use for your app depends on a few factors. The MVC model has been around for many years, it is well suited if you need more fine-tuned control over the page cycle process and it is also superior when it comes to unit testing etc, because it supports true separation of business logic and presentation layers.
However, do not dismiss Web Forms, the reality is you can continue to use the web forms framework and still have tight control over your page elements be simply moving away from pre-built server controls and integrating HTML5 standard controls. You can take advantage of new JavaScript frameworks like jQuery, you can improve search engine friendliness by using techniques like URL Re-Write, and you can reduce or eliminate post-backs by taking advantage of asynchronous frameworks like jQuery AJAX and SignalR.
The main reason I disagree with the accepted answer is the statement "writing stuff in MVC is much faster than in WebForms" is completely inaccurate. As any developer who has actually built MVC apps will tell you, it's actually much fast to build WebForms apps. The reason is not just learning curve, but the fact that while MVC gives you the benefit of "under-the-hood" access to the page cycle and more direct access to HTML output, is also the reason it takes longer to build MVC apps. Trust me, you will find yourself doing much more "plumbing" work than you ever did with "drag-and-drop" WebForms development.
The fact is, there was a lot of hype when ASP.Net MVC first came out and too many developers assumed it was a replacement for Web Forms. It hasn't. As I stated in the beginningm both frameworks are great, they both have their pros and cons. I would guess that 90% of developers are still building new apps in WebForms.
That's my 2c.
I've been learning ASP.NET MVC for about a month now and I'm certainly sold on its benefits but I realize it is not applicable to all situations.
I've read in several places that ASP.NET MVC is not ideal for data-intensive applications:
Example 1: "Data Driven Application – life would be MUCH easier using WebForms if the application is data heavy"
Example 2: Nick Berardi's book suggests that you side with Web forms if your application is "data-heavy"
Can someone clarify as to why ASP.NET MVC is ill-suited towards data-heavy applications and why Web forms are more appropriate? Also, where does one draw the line between data-heavy applications and other applications? Are we talking quantity of data (millions of records) or are we talking large data models?
I would really like this clarified as well, as I have found the exact opposite to be true, and I think stackoverflow.com is evidence of the suitability of MVC to data-driven apps.
I didn't bother reading much of the second link, but the assertions in the first are not qualified, and many of them seem wrong to me. The stated weaknesses of WebForms, though, would be enough to drive me from using it for a data-intensive app:
UI logic coupled with the code, and thus is hard to separate.
Harder to unit test, so difficult to employ TDD.
Heavy page sizes due to view state management.
The stated weaknesses of MVC are quite flimsy:
Not event driven, so maybe difficult for people who know only Asp.Net Webforms to wrap their minds around it.
Third party control library support is not that strong.
No ViewState(this is also a strength).
The first one can be seen as a plus as much as minus. The second is just wrong as MVC apps can leverage traditional server-side controls if they wish, as well as make use of the rich library of client-side controls and libraries. The third, well I don't think I even need to speak to that one...
You have to be wary when reading articles like this on the internet - they sound authoritative and comprehensive, but where is the meat? Why are the stated weaknesses an issue? It is not enough to just throw opinion out there as fact. They should be backed up with metrics, such as when using platform x over y, developers unfamiliar with either platform were able to complete an application 30% faster, or platform x resulted in 25% fewer lines of code, or fewer levels of indirection, or whatever.
The idea that RAD is a plus is another one that bears careful examination: RAD is fast until you want to do something a particular control was not designed for, and then you hit a brick wall. It is a leaky abstraction and when it fails, you are suddenly confronted with the full complexity of understanding the design framework and code of the given control. This can be quite a setback, and the source code for these controls is not always available.
Doesn't make much sense to me. They might be speculating on the difficulty of creating many models if you have lots of different types of data, or perhaps the relative difficulty of creating web forms in MVC.
However, ORMs (such as L2Sql, EF and Subsonic), model binders, and form generators (I can't find the link right now) pretty much hose those arguments.
Frankly I don't buy it.
I believe that these authors are talking about the ability to drag/drop data controls onto the page such as GridViews, FormViews, and other databound objects.
Say you have a database for your IT department, with a table for computers, a table for printers, one for software, etc. The UI for this is a very simple data management system, essentially a glorified MS Access.
Rather than writing an elegant web app, with beautiful HTML and a class library, you could simply create a quick/dirty WebForms app by dragging your data sources and controls onto the page in Visual Studio.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
It seems to me like there's a lot of sheeping going on, with everyone jumping on the MVC bandwagon.
Almost everyone is declaring WebForms as evil and satan without much persuasion. Then they go on to say that Controls are evil and they shouldn't be in a Web app. How are you going to show anything without any controls?
I remember when WebForms first came out and everybody loved them. I guess in a few years, people will sheep on to the next thing and declare MVC evil because you had to actually create controls to use MVC and they'll say you have to develop an application and not worry about the controls.
The way I see it MVC can be achieved in WebForms by not including the RunAt in the Form tag.
Then if you want to retrieve data, just use Ajax.
Can someone persuade me on why I should use MVC and not WebForms?
You shouldn't arbitrarily decide between one or the other; don't plump for the MVC framework just because it's the new kid on the block and everyone's singing its praises, especially not if you're comfortable with doing things using Web Forms. Practically every existing system is going to be using the older, more established technology, and there's nothing wrong with that.
While it's true that the MVC framework does allow for even easier separation of concerns (after all, that's what the MVC pattern is for), it also brings with it the responsibility of writing more HTML, and I think a slightly greater understanding of how the web works; not necessarily an unreasonable requirement, but you could argue it'll slightly slow you down the first few times you set about using it.
To be honest, I agree that Web Forms takes a lot of undeserved flack. Granted, there's a lot of magic going on in the background, and you get less control over some of the HTML output, but it's not exactly impossible to style with CSS (you end up using !important a lot, perhaps), and it's also not impossible to get some separation of concerns, even if it doesn't meet the purist's view of what that might be. You can still write pretty horrible code using the MVC framework. If you're looking to throw together something quickly, and you're good with Web Forms, then you're going to be able to achieve that very quickly, and it's nothing to be ashamed of, is it?
That's not to say, of course, that you should stick to your guns and ignore MVC either; it's a good framework (in fact, it's a very good framework) and it does confer several benefits which you might want to take advantage of in the long run. You also have to remember that it doesn't automatically nullify everything you learned about ASP.NET 2.0, either; a lot of the supporting architecture is embraced in the MVC framework, including things like the membership providers.
In Webforms:
Both Viewstate and Postbacks have been made lot of problems and increased complexity of the web application development. Many web pages having hundreds of KB size of Viewstate that affected the performance of the applications sometime.
Developers do not have the control of the rendering HTML of web forms and Server controls that render html with mixed inline style and deprecated tags that does not follows standards.
The page life cycle of the Web Form is too complex and has the tightly coupling between all things in the ASP.net framework and a single class is used both to display output and handles user input.
Unit testing is almost an impossible task. Today unit testing is very important in modern software development especially when we following agile methodologies and practices. Since web is a stateless thing, Events, Postbacks and Viewstate are not a good way.
With asp.net MVC all these things are simplified
If these things don't apply to you and you enjoy using Webforms then stick with what you do best. Don't try to fix something thats not broken.
For more detail refer to : Shiju's blog of ASP.net MVC Vs ASP.net Web Form
I see the key advantages of MVC as:
Much cleaner and simpler architecture. No more guessing which event you have handle to hook up your data correctly. No more having to insert a hook to "fix" a data binding problem because the framework doesn't do exactly what you want.
The framework doesn't get your way as much.
Decoupled architecture makes much more of the code more easily tested.
More closely aligned with the architecture of the web. For people coming from a WebForms background this may not seem to be an advantage until you embrace it and design for it instead of trying to write WebForms-like applications in MVC. Fortunately, I had explored Ruby on Rails some before using ASP.NET MVC and had already started to write my WebForms apps in a more RESTful way.
History/Ubiquity -- despite the fact that Microsoft is just rolling it out, MVC is a well-known and highly respected pattern. It's widely used for lots of web applications in many frameworks. Learning MVC will give you a leg up if you need to switch to a different technology where they are also doing MVC -- say RoR or Java/Struts.
The disadvantages:
Microsoft's implementation is new and not as mature.
Few third-party "controls"/plugins for round-trip use -- generic grids and such, though there are lots of plugins on the client-side via jQuery.
Requires unlearning some paradigms from WebForms to effectively use it.
The framework doesn't do as much heavy lifting for you; you'll have to learn some Javascript and write more client-side code because the framework won't inject it for you.
WebForms is a great framework, but it does requires for you to dig in and understand it. And yes, you should still be an expert in HTML and JavaScript. Every complaint that I ever hear about WebForms comes from someone who didn't take time to understand WebForms. Here are my answers to a few of them.
ViewState is Evil and will slow down the page
This reminds me of the programmers who made everything a global variable. You can certainly do it, but you SHOULD NOT! It's the same with WebForms and ViewState. Don't use ViewState unless you need to, and then only sparingly. There is nothing wrong in adding 1000 characters of view state to the html, if it will bring better user experience and/or speed up development time. You can experience the same problem in MVC by littering the page with hundreds of hidden input controls, and yes I've seen it. And by the way, ViewState is not "magical" it simply stores some data in a single input control and also encrypts it for good measure.
WebForms generates "ugly" html and is littered with long ids
Well, first of all, nobody actually looks at generated hmtl (did you look at google.com for example, it's a mess?!). Second, if you really care about generating specific html, it takes less than an hour to create your own re-usable component or control, with html of your choosing. Or you can take existing control, override rendering and use that control instead. Once again, you have to know where to go and how to do it, but once you know, it will be a great productivity boost without any sacrifices. Long ids are automatically generated to ensure uniqueness across the page. If you ever get a chance to develop a complex MVC view, you'll notice that you will inventing your own long id pattern, so that you can parse the form fields correctly on posting.
WebForms disallows multiple forms per page
I've been developing for 10 years and only once did I need multiple forms. And then I figured out that I didn't. You do have to understand HTTP requests and responses and how to achieve them with WebForms, but if you do, you'll never need multiple forms, nor will you ever think about "forms" at all.
WebForms pages are not testable
Absolutely not true. Even if you don't like MVP (which I don't), there are other techniques to test anything you want to test. It is true that if you just use pages in WebForms as is and put all logic in code-behid, it's probably not going to be testable and it's not a good idea. However, just like in MVC or Windows Forms applications, you can and you should, at least for complex views, create intermediary layers such as views and controllers. I prefer encapsulating functionality into user controls which implement an interface or inherit a base class. Then the page on which user controls reside on acts like a "master controller". Individual views, or user controls in this case, can be tested because they all implemement an interface or base class.
JavaScript is hard to do in WebForms
JavaScript is actually easier to implement in WebForms than in MVC. You sure have more options! But once again, you have to know WebForms well in order to realise this. In WebForms you can "inject" javacript with reusable components and controls. Or you can use it just like in MVC or plain HTML after changing a setting on the page to keep ASP implementing id naming scheme.
Having said all this, what does WebForms have to offer that MVC does not? Encapsulation and reusability of presentation components is by far the biggest, in my opinion. For complex views, I develop individual components (server or user controls) and than a custom controller or presentation factory weaves all of them into place. Additionally, design-time html is far cleaner in WebForms than in MVC, making design and styling a lot easier for properly trained graphic designers. It's cleaner because there is no programming code in design-time html, only markup (I don't use data binding expressions). And of course prototyping is much much easier in WebForms. For prototypes I will normally ignore all of the best practices and resort to wizards and ugly code-behind code that hits the database directly.
I could go on, but the main point I'd like to make is that WebForms and MVC are very different patterns and require different sets of knowledge and mindset to deliver great solutions. Both require as much of Web/HTTP/CSS knowledge as you can get. If I had to make one recommendation, generally, but not always, for high-traffic public website (such as blog) I may lean towards MVC. For complex web application, either internal/Intranet or membership external/Internet application, I would lean towards WebForms.
WebForms work fine and if you like them, continue to use them.
Three of the big advantages to MVC model as I see it are:
ViewState is gone, which could create a fairly sizable amount of traffic over the wire.
URLs can be remapped to mean something as is all the rage now.
Scaffolding. I don't know, personally I think this is satan and encourages terrible programming habits, but other seem to think its a beautiful idea.
It also encourages a a proper separation between business logic and presentation by enforcing the Model-View-Controller pattern, but good WebForm code can mostly do that as well.
So, really, if you are fine with the overhead of WebForms, and ok with ugly URLs and don't want scaffolding, stick with WebForms.
EDIT: Oh, I did miss one major advantage of "clean" urls. And MVC application is much friendlier for SEO. It also gives you fine control over HTML, but frankly, I don't consider that much of a step forward.
I think part of the problem, is that many people don't realise that MVC isn't an M$ invention, nor is it a replacement for webforms. Certainly, people like "new" things, and people like to throw buzzwords around, particularly to improve their resumes...
Finally .NET developers have some choice, and with that choice, they are being thrust some degree of responsibility for the decisions they make. I'm not surprised many webforms developers are nervous about this responsibility. It's not been there before. Ultimately, it can make you a better developer, or a worse one. It's now up to you.
People loved webforms, because it was better than ASP (Classic). And yes, in 5 - 10 years, I'm sure someone/group much smarter than I, will evolve a new paradigm/pattern.
Be careful with the sheep lable, as in a way, by holding onto a vendor specific pattern (webforms) you are potentially a bigger "sheep".
MVC is now across a variety of platforms, and means your potential to develop meaningful and stable solutions to problems can be dramatically increased. Or decreased. It's ultimately up to you. If you're not ready to go, then wait for ASP.NET MVC to mature. But don't close your mind to anything, particularly a pattern that is very very well established!
I recommend reading Rob Connery's extremely inflammatory blog. He certainly strummed my pain with his fingers! Then go and read RoR stuff, Cake, and Struts. All of these will start showing you the vision that the guys who brought MVC to .NET have (~ish) and hopefully will inspire you to see problems differently!
There have been several, more detailed, answers here, so rather than repeat anything they have said I'll try to keep my answer a bit more succinct. You shouldn't, necessarily use MVC over webforms, just as you shouldn't use webforms over MVC - they are both tools and are more, or less, appropriate in different situations. I was first exposed to MVC quite a few years ago on J2EE, when .NET was first coming out (I'm not sure the ASP.NET MVC was available at that time). It gives a really nice, clean framework and gives more "web" applications (i.e. request/response), but you can also add in a lot more client-side functionality using AJAX - I have done some really funky things using AJAX on a php app I wrote a while ago and that is all usable under MVC.
There are some things that MVC does better and some things that webforms do better, but if you don't know both technologies you can't choose the best one for the current project you are doing, so please don't do yourself a disservice - go and learn MVC. Even if you never use it directly, it may still give you useful "theory" knowledge you can apply in other tools. I try to learn as many different things as I can, as the more strings to my bow I have, the less likely it is that I will not be able to solve a problem (for example, in that php app, I used php, hooked into a bit of ASP, and even had DOS and *NIX batch/script files performing certain functions - each tool had its place and was best suited to the job to which it was allocated).
Not me. MVC is pretty cool in a resume, but for our customers (those who pay for our work), it's not a show stopper.
They usually want applications that are right, fast and secure. That's all. They will not want to change the third layer of the client part in three years ! In three years, they will change every thing or nothing at all.
Layers are fun to architect and to code, but they cost a lot to create and to maintain and they are not relevant to our customers. MVC is pretty cool but really useless and expensive.
Unless, of course, you are developping applications for 4 OS and 3 plateforms... But you will then be a minority.
:o)
This is a stupid discussion - they are different, ASP.NET MVC and WebForms are different technologies! I'm using MVC for all new projects, but when I am faced with a need for RAD I use WinForms, because it is simple and there are a lot of controls already written by gurus.
Stop discussing this. Who wants to understand difference? Just try both technologies and you will understand by yourself.
Last week , my boss ask my team to evaluate ASP.NET MVC, for next project.
all of us working with webform since .NET 1.1, we have no MVC experience before ,but all of my colleagues are interested in ASP.NET MVC ,But no luck , our finally answer is NO.
Because:
We believe although you are ASP.NET Guru, you can build a complex application in short amount of time. But if you change to ASP.NET MVC, the development time will take longer, every things need to using html helper, no web control, and many question ,keep opening the Firefox Tab with ASP.NET forum for ask How-To question.
We had see many times people say MVC provide better project management , but if it is a complex web site, I can imagine there are hundred <%=%> TAGs in one page, and keep open controller to see what to return, and keep opening model to see the logic.
I can say , MVC is not bad, but Webform is strong enough to handle the job.
It will take several weeks to change over to a new technology, or a "way of thinking".
With MVC, you have to get away from old ASP.NET Forms way of thinking "complex web application" in that "how many pages we have, over 300 pages! that would be huge!". You change the view of your entire application. You shift from old thinking of "what page need to create next" to the MVC way of thinking of "what function do we need to implement next".
For example, I myself took control of a project that has over 3300 files in the 'web' project alone (plus the 11 supporting assemblies). One thing that I am architecting is how MVC will drastically cut down the number of physical files down to around 310 or so. How? Because I am moving away from "here's one page. Here's another page." to a "here's the function I want to implement" way of thinking.
By looking at pages as the function you are trying to accomplish, you instead start abstracting pieces of that page out into common functionality.
MVC can greatly scale with this way-of-thinking because now you have a template for the way you want it to look, you just need to implement another "function" to change the look of that View (html) you want to render. No 2nd page, no additional controls, etc.
Now, as for "no web controls" as you mentioned: again, this calls for a different way of thinking. There is the HtmlHelper that is used for basic rendering and encoding. I use the same concept with an abstracted class called MyProjectHelper that renders my "functions" onto the page (functions=code).
For example, I always created a Server Control for my DisplayNames in the past. This allowed me to control the way that DisplayName was shown, especially with a switch to Facebook Connect and other things. With MVC, I no longer use a "server control", but a "function" on a ViewModel to render that text: CollegeProjectViewModel.RenderDisplayName(). Since this is only part of the UI layer, this will render the Anchor as needed with any options I wish (of course, the abstract is inherited by the CollegeProjectViewModel that picks up on the "basic" text rendering).
MVC's power lies in the ability to no longer require a "webpage", but instead "functions" or methods of what you want to do with your site. By changing to this way of thinking, you really can scale with as many method you create on your Controllers. It really speeds things up on a mass scale IMO.
I worked on a MVC project at my last company for 6 months (we were using the CTP builds and eventually the beta builds). Initially, it was fun and exciting and it felt like we were really on to something. Like a lot of .NET developers out there, we were tired of the leaky abstractions of Web Forms.
However, as time progressed, we started to question our decision. The UI development was taking like 80% + of our time. We had to build all our UI from the ground up. Half the time it felt like we were reinventing the wheel. Most of our Rich UI came from JQuery combined with Custom HTML Helpers, which were fun to design, but time consuming.
There were other problems we were encountering, like the necessity of DTO-like objects to map from our business objects (fetched from a repository backed by NHibernate) to the Views. And our controllers, which were apparently supposed to be lightweight and easy to maintain, were becoming increasingly cluttered and we were constantly arguing about the proper way to implement controller inheritance.
In retrospect, I feel all the problems we were facing were due to our lack of experience and understanding of MVC. We all liked the idea of MVC, but just didn't have the practical experience and know-how to use it effectively on what I consider to be a very complex (imagine something along the lines of Sales Force, but with better reporting) application.
-- UPDATE --
Been using it the last month to work on a very small project and so far things are going smoothly. It's much easier to work with than the CTP versions I was using a year ago. I am currently looking at my own personal solution for complex "grid views", and then I might switch over completely for most projects. However, Dynamic Data has been treating me proper and I am sort of torn between the 2.
-- UPDATE 2011 --
After several various sized MVC projects over the past year or so, I have become somewhat of a convert. All the real issues I had with it have mostly been resolved in the latest versions (2 & 3), particularly the ones dealing with model validation and binding to and from views.
One thing though: it still can be a bit tedious to create highly interactive data grids, something that is still somewhat easier in WebForm. However, there are 3rd party offering that provide useful MVC extensions making this less of a concern. Personally, I use Telerik's offerings to great ends.
Among many benefits to using MVC is the removal of the viewstate hog.
If your Webform app is really large and uses a lot of server-side items that bloat your line with viewstate, then MVC may actually help you, even though it may take longer to develop.
On the flip side of that, be on the lookout for .NET v4.0 which will allow you to control viewstate on the control level instead of just on the page level. That will make MVC even less palatable overall.
I think you're right that it will take your team time to adapt to the new technology, and this will take extra time in the short term.
I wouldn't start using MVC in production until are some decent books out and the team has had a chance to read the books and play with the technology. Otherwise it seems your dev team will spend a lot of time watching screencasts and fishing for documentation.
I came from webform development (just like you), from 1.0 up until 3.5. When I discovered MVC (CTP), it took me about 6 months to convince my peers (and my boss) that it is the way to go.
Some of the highlights of my arguments:
Full control of HTML
TRUE AJAX (instead of update panel)
Possibility of using jQuery exponentially increased
No VIEWSTATE
Separation of concern
.. and .. (drum roll) ... faster development
Although #6 is a little bit subjective, but I did try to prove it by building prototypes. For my prototype, I built a simple dashboard web app, using both webform and asp.net mvc. I showed my peers and my boss the result, as well as the complexity of building and maintaining each one. In the end, we migrate our main methodology from webform to MVC.
It is true that it takes a while to "unlearn" some webform paradigm. But once you get it, MVC is so much easier to pick up and you can run with it.
In webform, yes it is powerful, but often in large projects, we spend a lot of our time trying to "customizing" or "coercing" a server control to behave and perform like the way we want it - and as complexity of the system goes up, the complexity of this customization also goes up exponentially.
TRUE AJAX is also quite difficult in webform. UpdatePanel has its role, but nested update panels has its own share of problems as well.
For me and my peers, it boils down to the ability to control our HTML/code/AJAX - instead of automatically generated 90% by the framework but we have to spend a lot of time and effort to get the rest 10%.
ASP.NET MVC, combined with jQuery, and your prefered biz tier framework or ORM, is extremely powerful. So far to date, we have released 3 production releases with ASP.NET MVC and they all perform well - heck take a look at stackoverflow.com (it uses MVC btw).