I still have my reservations about MVC because I can't use the ASP.NET server controls like the gridview which increases my productivty. I am not happy about creating my own foreach loops instead of using the repeater, for example.
The MVC pundits here and elsewhere keep mentioning that with MVC they can write pure valid html and xhtml. My question to them is "Why is this important"? As long as the page renders properly under all the browsers, who cares? If you use an
html validator and validate any popular site like amazon.com or ebay.com, you'll get a ton of errors. No one is saying these sites suck because they don't validate 100%! Even stackoverflow.com which uses MVC has a lot of
errors. Site visitors don't care. No one is going to base their use of a site by the site's adherence to web standards. Is anyone checking the site's footer to see if one of the w3c standards logos is visible.
I am getting sick and tired of standards talk from people who push for it but who don't actually use them and adhere to them.
No one is looking at an open source app and saying "I am not going to use this useful app because the source code looks messy or because there are no comments or because I don't like the way the developer uses variable names".
Man, when I first had a go at this take on MVC I wasn't conviced either. Just because some people get fixated on standard html, doesn't mean you have to as well, but look at the ways that you can build grids and other repeating controls using partials inside
your views, and I'm sure you'll see that the main benefit is that you can easily see how these repeating objects are being built up.
This is where the use of views that are strongly typed to your model really pays you back in terms of productivity.
People in these early are keen to point out what they see as the benefits, but you can make ASP.Net MVC solutions as good or as bad as you like. You can focus on areas like w3c standards, but a balanced approach will yield productivity and good quality solutions.
Please don't give me a load of grief if you disagree.
I'm a standards advocate (don't flame me...), and I use MVC specifically because of how much control it gives me. Don't get me wrong, the server controls are nice and all, but they're also quite bloated, and don't give you ideal control. For example, and
you should know this, the rendered IDs for elements suck, especially when you have a couple of elements nested together. Also, if you view the generated source on the controls, you can easily see it's highly bloated. For example, why are simple tables over-complicated
with additional crap.
In terms of user interaction, the user may not see anything visually (which I doubt is true for 90% of times), but they will notice speed degradation due to how much bloat they have to download. Also when you start with pure, clean HTML, it becomes way easier
to work it over time and as the application progresses. CSS becomes much easier to, and you reduce the amount of browser quirks you might possibly have. Also, most server controls render in tables, when a simple div with some slightly more advanced CSS would
have done the same job and reduced the complexity.
Anyway, that's my take on it.
P.S. I am one of the guys that talks about standards, and strictly follows them to the T whenever possible.
I agree that server controls are more bloated but are they more bloated to a degree that they are causing issues? I create Intranet apps for my company. I don't care if the html is more bloated. We have lots of bandwidth and we are not paying for traffic.
On the Internet the apps still load fast. I guess I need to ask dialup users if they experience slowness.. but where are these dialup users?
If you take commercial grids like Telerik or DevExpress, they claim they load fast and their demos are nice. Their grids looks cool and have a ton of features. They claim they are standards compliant and work under different browsers. GREAT! This means
I don't have to worry about any of this stuff. MVC comes along and tells me I can't have any of these. You will have to manually code all this but you will get mean clean html. My company is not paying me to produce clean mean html. It's paying me to produce
business apps which users can use and which users like to use.
This is like all the discussions about performance. If you do it the easy productive RAD way, it's 50 milliseconds slower. The performance pundits say it's bad and it sucks. Yeah like the human will notice the 50 ms slowness. The page still loads under a
second so who cares if it's 50s slower or 100 ms..?
I like to use CSS but I will revert to tables if CSS is a hassle. It's a lot easier to create 5 column form in tables than CSS so I use tables. I get working in FF but it's not the same in IE. It's lools good in IE 7 but not in IE 6. If you use tables,
it looks right everywhere.. That's why grids use tables. Because it's consistent across browsers. If all browsers understand CSS the same way, we all would dump html tables.
As for the client.ID issue, MS is working to resolve this issue in their next server controls. Meanwhile I am OK with using document.getElementById('<%=txtFirstName.ClientID%>');
BTW, Telerik's controls work with MVC according to their site. If I can get the best of both worlds, that would be great for me.
I don't think MVC is all about 'standards compliance'. It makes it easy to be compatible, but that's not the major goal. On the other hand, what you can say that 'Testing' is one of the major benefits of using MVC. It's is a lot easer to test an MVC app
then WebForms - because webforms requires you to run a hosting environmet to get almost anything tested, which can be magnetudes slower, and complicated to setup then 'pure' unit testing.
As for MVC v WebForms in general, there is a place for both: As you mentioned using server controls makes it very easy because of the component model and tooling using that. However, when you start tweaking the details (outside the controls parameters) you
either end up with very complicated solutions, or writing our own control, or most likely stepping outside the webforms model and hacking a little javascript here and another hidden div there, and so on.
On the other hand using MVC you have the full control and possibilty to do any change as long as it is css html and javascipt. This comes with a price of productivity sometimes. The reson for that is because of the model, tooling is not as we are used to
be and because it is still new there isn't much of it. As for the 'model' (especially from tooling perspective) I think it's worth mentioning, it is not a component based model. Instead it is more based on templates and boiler plate code generation (i.e. scaffolding).
In the end we will have to wait and see if there will be a best of both worlds solution, but for now MVC and WebForms have different set of audiences depending on the projects in general (technology needs, development style etc).
Man, you say "who cares as long as the page renders fine on all browsers". Well that's right.
Does your work render "fine" on user agents for disabled people, mobile devices and so on? Is your content accessible, reusable and redistribuitable? Do you think amazon and the other sites you mentioned offer a good usability to all kind of people? Well,
I can tell you. They DO NOT.
You know something? The web is for everyone, not just for lucky people like you and me who can use both hands, have a good eyesight and don't have learning problems.
You're (no offence here) the average "wannabe web developer" who hasn't the slightest idea of what this work is about. You drag&drop some "web controls" on the designer and you're making a web site. No wait, you are not. You're telling VS what you have in
mind, without having the knowledge on how to do it, and let VS translate your thoughts in html. Too bad that web forms does this work horribily, but it's not its fault. As an automation, a paradigm, it does what it can. But they quality can't be the same as
of the work of a professional, not even close.
And even if you don't care about this.. well.. there are standards, standards are, in every aspect of life, a "common language to make your work undestandable by others". If you don't talk standards, others won't understand you, at best they can try to interpret
what you mean.
A web site that is not standards compliant is a bad web site, period. No matter how fine it renders on your browser or how cool it looks.
And lastly, your assertions are a real insult to people who put real effort in making the things the way they should be.
With respect, web standards are not the main reason for keeping your HTML out of a webforms' clammy, dirty hands!
A little background. I was a Perl programmer before I moved to ASP, and my company didn't use any frameworks. As a result, I have a pretty intimate working knowledge of how
HTTP requests worked, and a fair degree of expertise in HTML,
CSS and Javascript to boot. I had hoped to leverage these skills in my new job. As you can imagine, I had palpitations when I first saw the
HTML output from a simple ASP control, and my heart skipped a beat when I realised that
ASP was quietly rewriting all of my ID attributes into strange, qualified nonsense that neither Javascript nor
CSS could rely on.
These are not minor issues. Here are a few of the problems I have had with webforms:
Trying to style a datagrid, I found it absolutely impossible to set borders on any of the table elements using
CSS—which, after all, is the correct tool for the job. On investigation, I discovered that the datagrid enforces a border attribute on the table it outputs which cannot, under any circumstances, be removed. (The most you can do is set it to zero,
which means you cannot have any borders in your table.) I was finally able to fix this by installing the
CSS friendly control adaptors.
Any time I wrote Javascript to manipulate the contents of a control, I'd find the ID attribute magically demolished by underscore-separated qualifications. Since the most fundamental function of Javascript—for the purposes of
DOM manipulation—is
getElementById
, which depends upon static, reliable element IDs, I found myself resorting to the most remarkable workarounds (if you can euphemise the necessary hacks thus) to ensure that my scripts would
work. If you plan to use any Javascript frameworks for complex interactivity, this will become a major issue.
CSS is similarly afflicted when controls mess with your IDs. One of the most important
CSS selectors is the ID selector, which (as you might have guessed) also assumes that your IDs will not be magically mangled by external forces.
The postback mechanism. Need I say more? I suppose I should. Basically, it was a very clever idea, but when you repurpose the hyperlink—the most fundamental element of the
HTML Web—you better be damn sure that it's watertight. Postbacks aren't. For one thing, disable Javascript and see any "link buttons" you've used fail spectacularly. Also, the postback Javascript broke my standard form validation script. I never
found an elegant way to get around that.
Viewstate is another very clever idea, but also
a performance drain if you aren't circumspect. There are other ways to preserve state which don't depend upon messy Javascript hijacking every GET request and massive values for a hidden (and you might sigh, but wholly invalid) input element—cookies, for
example, or server-side sessions. And having viewstate enabled on controls by default was a bad decision, in my opinion.
ASP.NET's Ajax toolkit, while fantastically easy to use, is also extremely bloated compared to what an experienced scripter can achieve. For the ease-of-use of update panels, you pay the cost of several kilobytes of Javascript effecting complete postbacks
in order to extract a bucketload of unadulterated HTML to be injected directly into your page. (I can typically make a saving of a few hundred percent or more by writing my own JSON, and in extreme examples several thousand percent.) This is simply
untenable for any heavily interactive application.
Finally, ASP webforms encourage developers to take a dubious perspective towards the actual mechanics of serving web pages. This means that they will be in heaps of trouble if
the rich abstractions they rely on leak (as described in the above examples), and seriously limits their productivity if they are ever called upon to do something out-of-the-ordinary—e.g. write some particularly clever interactive Javascript.
All this aside, MVC is an extremely useful framework in its own right, and in particular has turned out to be perfect for my current project, wherein a separation of logic from presentation is exactly what we require. It may be overkill for
small projects, but its advantages go far beyond being able to put a little badge in the bottom of your page.
Oh, yes, and one final note: writing valid HTML has saved my bacon many times. The
HTML Validator extension for Firefox helps no end in spotting and tracking down bugs, so long as the rest of your markup is good.
Matteo Mosca: You need to stop calling every WebForm developer a wannabe web developer. Before posting in this forum, I did a search on 'mvc gridview' and I have seen you reply to most of them playing the same record. MVC is the silverbullet
and it's the best thing since sliced bread.. or even better.
Amazon.com does offer different versions to different devices, Don't tell me your MVC site is accessible to all devices the same way. The devices work differently. They don't support everything like a full blown browser.I can use WebForms and still produce
sites which work for different readers. Yes I have to sniff the user agent. I bet MVC has to do the same thing. MVC is not the solution to all problems and stop preaching this.
I didn't say standards are bad. I am saying you can still make usable sites without implementing every single standard.
And stop putting words in my mouth and accuse me of not knowing anything about the web. You are offensive. I have seen you call people who use WebForms idiots. I guess than includes everyone before 2007.
Jordan Gray: You can style borders in a grid. For example if you want to style a cell's border, give the grid a css class decleration and do something like this:
For the ID's, I use something like "document.getElementById('<%=txtFirstName.ClientID%>')". It's just a few more characters to type than document.getElementById('txtFirstName'). On the plus side, you're guaranteed the ID's are unique. Ok so you probably
have to use more css classes but in controls with repeated elements, you have to use unique ID's anyways. I don't mind having asp.net name them for me.
You don't have to use linkbuttons. When you have more features, you choose what you like frtom the toolbox. No one is forcing you to use a feature or control. If I know that all my users use IE and have Javascript enabled (as in Intranets), I don't have
to worry about certain limitations or what-if scenarios.
If you are aware of the html the controls produce, why wouldn't you be able to use Javascript to do whatever you want? Can you give an example?
If you have issues with a WebForm control, it's mostly the control's designer fault, not the WebForm in general. A developer can develop a control which produces tight standards conforming html.
My beef with the current MVC is lack of MVC controls. I can just wait for v2.0 of MVC so I can be more productive with it.
As for Joel's article, I don't agree with everything he ever says. So what's his point? Do not use SQL for querying databases? In 99.9% of cases the query engine produces the correct plan. If not, then just customize it or fix it. It's not a show stopper.
I certainly will not craft a new query language to get everything. I am positive no one can. Joel created his own langauge to develop his software with. How many people in this world will go to that extreme?
For the ID's, I use something like "document.getElementById('<%=txtFirstName.ClientID%>')". It's just a few more characters to type than document.getElementById('txtFirstName'). On the plus side, you're guaranteed the ID's are unique. Ok so you probably have
to use more css classes but in controls with repeated elements, you have to use unique ID's anyways. I don't mind having asp.net name them for me.
I think this is kind of the border line where you should start thinking about using Mvc or possibly write your own server control. Don't get me wrong! I am not saying WebForms is 'bad'. On the contrary, I think it is a great component framework, which enables
all that productivity we enjoy. And when it comes to details, to stay true to the framework is not everyone's cup of tea. Developing server controls requires much deeper knowledge and experience of webforms than just being able to use them. And added complexity
might not worth it sometimes. And once again (as I mentioned in my previous post in this thread) development method one chooses influences the decision. If you want to work with unit tests, for example, you probably would want to work with Mvc.
As for productivity, have a look at ASP.NET Dynamic Data as well. It's not part of Mvc but one of its relations.
Tony2005
Member
139 Points
59 Posts
MVC and the HTML purists
Nov 13, 2008 05:43 PM|LINK
I still have my reservations about MVC because I can't use the ASP.NET server controls like the gridview which increases my productivty. I am not happy about creating my own foreach loops instead of using the repeater, for example.
The MVC pundits here and elsewhere keep mentioning that with MVC they can write pure valid html and xhtml. My question to them is "Why is this important"? As long as the page renders properly under all the browsers, who cares? If you use an html validator and validate any popular site like amazon.com or ebay.com, you'll get a ton of errors. No one is saying these sites suck because they don't validate 100%! Even stackoverflow.com which uses MVC has a lot of errors. Site visitors don't care. No one is going to base their use of a site by the site's adherence to web standards. Is anyone checking the site's footer to see if one of the w3c standards logos is visible.
I am getting sick and tired of standards talk from people who push for it but who don't actually use them and adhere to them.
No one is looking at an open source app and saying "I am not going to use this useful app because the source code looks messy or because there are no comments or because I don't like the way the developer uses variable names".
Tony
tortuga
Member
91 Points
45 Posts
Re: MVC and the HTML purists
Nov 13, 2008 09:17 PM|LINK
Man, when I first had a go at this take on MVC I wasn't conviced either. Just because some people get fixated on standard html, doesn't mean you have to as well, but look at the ways that you can build grids and other repeating controls using partials inside your views, and I'm sure you'll see that the main benefit is that you can easily see how these repeating objects are being built up.
This is where the use of views that are strongly typed to your model really pays you back in terms of productivity.
People in these early are keen to point out what they see as the benefits, but you can make ASP.Net MVC solutions as good or as bad as you like. You can focus on areas like w3c standards, but a balanced approach will yield productivity and good quality solutions.
Please don't give me a load of grief if you disagree.
Happy coding,
tortuga
bulgarian388
Member
22 Points
110 Posts
Re: MVC and the HTML purists
Nov 13, 2008 10:37 PM|LINK
I'm a standards advocate (don't flame me...), and I use MVC specifically because of how much control it gives me. Don't get me wrong, the server controls are nice and all, but they're also quite bloated, and don't give you ideal control. For example, and you should know this, the rendered IDs for elements suck, especially when you have a couple of elements nested together. Also, if you view the generated source on the controls, you can easily see it's highly bloated. For example, why are simple tables over-complicated with additional crap.
In terms of user interaction, the user may not see anything visually (which I doubt is true for 90% of times), but they will notice speed degradation due to how much bloat they have to download. Also when you start with pure, clean HTML, it becomes way easier to work it over time and as the application progresses. CSS becomes much easier to, and you reduce the amount of browser quirks you might possibly have. Also, most server controls render in tables, when a simple div with some slightly more advanced CSS would have done the same job and reduced the complexity.
Anyway, that's my take on it.
P.S. I am one of the guys that talks about standards, and strictly follows them to the T whenever possible.
Tony2005
Member
139 Points
59 Posts
Re: MVC and the HTML purists
Nov 14, 2008 12:09 AM|LINK
I agree that server controls are more bloated but are they more bloated to a degree that they are causing issues? I create Intranet apps for my company. I don't care if the html is more bloated. We have lots of bandwidth and we are not paying for traffic. On the Internet the apps still load fast. I guess I need to ask dialup users if they experience slowness.. but where are these dialup users?
If you take commercial grids like Telerik or DevExpress, they claim they load fast and their demos are nice. Their grids looks cool and have a ton of features. They claim they are standards compliant and work under different browsers. GREAT! This means I don't have to worry about any of this stuff. MVC comes along and tells me I can't have any of these. You will have to manually code all this but you will get mean clean html. My company is not paying me to produce clean mean html. It's paying me to produce business apps which users can use and which users like to use.
This is like all the discussions about performance. If you do it the easy productive RAD way, it's 50 milliseconds slower. The performance pundits say it's bad and it sucks. Yeah like the human will notice the 50 ms slowness. The page still loads under a second so who cares if it's 50s slower or 100 ms..?
I like to use CSS but I will revert to tables if CSS is a hassle. It's a lot easier to create 5 column form in tables than CSS so I use tables. I get working in FF but it's not the same in IE. It's lools good in IE 7 but not in IE 6. If you use tables, it looks right everywhere.. That's why grids use tables. Because it's consistent across browsers. If all browsers understand CSS the same way, we all would dump html tables.
As for the client.ID issue, MS is working to resolve this issue in their next server controls. Meanwhile I am OK with using document.getElementById('<%=txtFirstName.ClientID%>');
BTW, Telerik's controls work with MVC according to their site. If I can get the best of both worlds, that would be great for me.
zsuzen
Participant
768 Points
150 Posts
Re: MVC and the HTML purists
Nov 14, 2008 12:45 AM|LINK
I don't think MVC is all about 'standards compliance'. It makes it easy to be compatible, but that's not the major goal. On the other hand, what you can say that 'Testing' is one of the major benefits of using MVC. It's is a lot easer to test an MVC app then WebForms - because webforms requires you to run a hosting environmet to get almost anything tested, which can be magnetudes slower, and complicated to setup then 'pure' unit testing.
As for MVC v WebForms in general, there is a place for both: As you mentioned using server controls makes it very easy because of the component model and tooling using that. However, when you start tweaking the details (outside the controls parameters) you either end up with very complicated solutions, or writing our own control, or most likely stepping outside the webforms model and hacking a little javascript here and another hidden div there, and so on.
On the other hand using MVC you have the full control and possibilty to do any change as long as it is css html and javascipt. This comes with a price of productivity sometimes. The reson for that is because of the model, tooling is not as we are used to be and because it is still new there isn't much of it. As for the 'model' (especially from tooling perspective) I think it's worth mentioning, it is not a component based model. Instead it is more based on templates and boiler plate code generation (i.e. scaffolding).
In the end we will have to wait and see if there will be a best of both worlds solution, but for now MVC and WebForms have different set of audiences depending on the projects in general (technology needs, development style etc).
--Ziya
Sgro
Participant
782 Points
352 Posts
Re: MVC and the HTML purists
Nov 14, 2008 10:42 AM|LINK
Man, you say "who cares as long as the page renders fine on all browsers". Well that's right.
Does your work render "fine" on user agents for disabled people, mobile devices and so on? Is your content accessible, reusable and redistribuitable? Do you think amazon and the other sites you mentioned offer a good usability to all kind of people? Well, I can tell you. They DO NOT.
You know something? The web is for everyone, not just for lucky people like you and me who can use both hands, have a good eyesight and don't have learning problems.
You're (no offence here) the average "wannabe web developer" who hasn't the slightest idea of what this work is about. You drag&drop some "web controls" on the designer and you're making a web site. No wait, you are not. You're telling VS what you have in mind, without having the knowledge on how to do it, and let VS translate your thoughts in html. Too bad that web forms does this work horribily, but it's not its fault. As an automation, a paradigm, it does what it can. But they quality can't be the same as of the work of a professional, not even close.
And even if you don't care about this.. well.. there are standards, standards are, in every aspect of life, a "common language to make your work undestandable by others". If you don't talk standards, others won't understand you, at best they can try to interpret what you mean.
A web site that is not standards compliant is a bad web site, period. No matter how fine it renders on your browser or how cool it looks.
And lastly, your assertions are a real insult to people who put real effort in making the things the way they should be.
Web Developer
IWA Member
Jordan Gray
Member
18 Points
21 Posts
Re: MVC and the HTML purists
Nov 14, 2008 12:39 PM|LINK
With respect, web standards are not the main reason for keeping your HTML out of a webforms' clammy, dirty hands!
A little background. I was a Perl programmer before I moved to ASP, and my company didn't use any frameworks. As a result, I have a pretty intimate working knowledge of how HTTP requests worked, and a fair degree of expertise in HTML, CSS and Javascript to boot. I had hoped to leverage these skills in my new job. As you can imagine, I had palpitations when I first saw the HTML output from a simple ASP control, and my heart skipped a beat when I realised that ASP was quietly rewriting all of my ID attributes into strange, qualified nonsense that neither Javascript nor CSS could rely on.
These are not minor issues. Here are a few of the problems I have had with webforms:
All this aside, MVC is an extremely useful framework in its own right, and in particular has turned out to be perfect for my current project, wherein a separation of logic from presentation is exactly what we require. It may be overkill for small projects, but its advantages go far beyond being able to put a little badge in the bottom of your page.
Oh, yes, and one final note: writing valid HTML has saved my bacon many times. The HTML Validator extension for Firefox helps no end in spotting and tracking down bugs, so long as the rest of your markup is good.
Tony2005
Member
139 Points
59 Posts
Re: MVC and the HTML purists
Nov 14, 2008 09:20 PM|LINK
Matteo Mosca: You need to stop calling every WebForm developer a wannabe web developer. Before posting in this forum, I did a search on 'mvc gridview' and I have seen you reply to most of them playing the same record. MVC is the silverbullet and it's the best thing since sliced bread.. or even better.
Amazon.com does offer different versions to different devices, Don't tell me your MVC site is accessible to all devices the same way. The devices work differently. They don't support everything like a full blown browser.I can use WebForms and still produce sites which work for different readers. Yes I have to sniff the user agent. I bet MVC has to do the same thing. MVC is not the solution to all problems and stop preaching this.
I didn't say standards are bad. I am saying you can still make usable sites without implementing every single standard.
And stop putting words in my mouth and accuse me of not knowing anything about the web. You are offensive. I have seen you call people who use WebForms idiots. I guess than includes everyone before 2007.
Tony2005
Member
139 Points
59 Posts
Re: MVC and the HTML purists
Nov 15, 2008 12:44 AM|LINK
Jordan Gray: You can style borders in a grid. For example if you want to style a cell's border, give the grid a css class decleration and do something like this:
.MyGrid td {
color:#000;
padding:2px 18px;
border-right-style:solid;
border-right-width:1px;
border-bottom-style:solid;
border-bottom-width:1px;
}
You can also use ControlStyle-CssClass.
For the ID's, I use something like "document.getElementById('<%=txtFirstName.ClientID%>')". It's just a few more characters to type than document.getElementById('txtFirstName'). On the plus side, you're guaranteed the ID's are unique. Ok so you probably have to use more css classes but in controls with repeated elements, you have to use unique ID's anyways. I don't mind having asp.net name them for me.
You don't have to use linkbuttons. When you have more features, you choose what you like frtom the toolbox. No one is forcing you to use a feature or control. If I know that all my users use IE and have Javascript enabled (as in Intranets), I don't have to worry about certain limitations or what-if scenarios.
If you are aware of the html the controls produce, why wouldn't you be able to use Javascript to do whatever you want? Can you give an example?
If you have issues with a WebForm control, it's mostly the control's designer fault, not the WebForm in general. A developer can develop a control which produces tight standards conforming html.
My beef with the current MVC is lack of MVC controls. I can just wait for v2.0 of MVC so I can be more productive with it.
As for Joel's article, I don't agree with everything he ever says. So what's his point? Do not use SQL for querying databases? In 99.9% of cases the query engine produces the correct plan. If not, then just customize it or fix it. It's not a show stopper. I certainly will not craft a new query language to get everything. I am positive no one can. Joel created his own langauge to develop his software with. How many people in this world will go to that extreme?
Tony
zsuzen
Participant
768 Points
150 Posts
Re: MVC and the HTML purists
Nov 15, 2008 10:00 AM|LINK
I think this is kind of the border line where you should start thinking about using Mvc or possibly write your own server control. Don't get me wrong! I am not saying WebForms is 'bad'. On the contrary, I think it is a great component framework, which enables all that productivity we enjoy. And when it comes to details, to stay true to the framework is not everyone's cup of tea. Developing server controls requires much deeper knowledge and experience of webforms than just being able to use them. And added complexity might not worth it sometimes. And once again (as I mentioned in my previous post in this thread) development method one chooses influences the decision. If you want to work with unit tests, for example, you probably would want to work with Mvc.
As for productivity, have a look at ASP.NET Dynamic Data as well. It's not part of Mvc but one of its relations.
--Ziya