Last post Mar 21, 2010 06:01 AM by gunteman
Mar 14, 2010 10:49 PM|pattioso|LINK
I think most people would probably say, if you need RAD, go for webform, else use ASP.NET MVC for architecture elegance. But the MVC framework is still in early stage, I doubt if this would fit for building large enterprise solutions, what is your opinion
on this? Assuming that you are asked by CIO to make that architecture decision to select one for an upcoming big project.
Mar 15, 2010 01:35 AM|ignatandrei|LINK
MVC is on release 2 - not so "early stage"
If your developers do not know good html, jscript- stick with web forms.
If you want to test throughfullly your product - stick with MVC
Mar 15, 2010 02:59 AM|pattioso|LINK
When I say early stage I mean the helper classes etc can still be much further enriched to enhance developer productivity, I do not think having MVC-specific server controls is something unrealistic, but the challenge is what Microsoft would do for ASP.NET
MVC after release 2, it could be painful if a team of enterprise developers to build some framework based on V2 just to find out a few months later that MS is coming up with something as well.
Personally I think the new release is more like a V1.5 than V2
Mar 15, 2010 03:12 AM|ignatandrei|LINK
you can see what's next for v3 at http://aspnet.codeplex.com/wikipage?title=Road%20Map&referringTitle=MVC
For my part I consder that the benefits outweigh the lack of controls
Mar 16, 2010 09:51 AM|pattioso|LINK
Thanks for the link, I am waiting to see more responses to that thread, I hope the community can strongly influence the evolution of ASP.NET MVC so it can in near future empower enterprise solution building as effective as Webform does today, I think the
roadmap for V3 does not seem to be aggressive enough.
Mar 16, 2010 10:21 AM|ignatandrei|LINK
I think the roadmap for V3 does not seem to be aggressive enough.
What do you think it will be an "aggressive" approach?
Mar 16, 2010 10:54 AM|pattioso|LINK
Having a set of ASP.NET MVC framework compatible controls that we can drag and drop to the view, with design time support similar to what webforms server control has today, things like this will definitely be very helpful for RAD under MVC.
I don't think ASP.NET MVC necessarily must be != RAD, it is only about architecture improvements and correcting what webform suffers, but it need not limit people to do only basic web coding techniques.
Mar 16, 2010 11:34 AM|ignatandrei|LINK
For my part the Opinionated helpers(DisplayTemplate/EditTemplate) , the Wizard to generate pages(list, edit, create, update) from Model , the T4 generator and Areas are enough to have a good start...
Mar 16, 2010 07:17 PM|gunteman|LINK
I don't think ASP.NET MVC necessarily must be != RAD
I don't think RAD must necesarily be "drag and drop" or "controls". For me, Rapid Application Development is what happens when the tools get out of the way and only provide expected behavior. Currently, I feel that MVC does this a lot better. Design time
support is highly over rated, IMHO. I never use it, and I can't remember seing anyone outside of Microsoft demos doing it either.
That said, I won't abandon WebForms just yet. There are still scenarios where it's beneficial to e.g load controls from a plugin system or have controls which are aware of the context they're in and render accordingly. But for all new projects I now ask
myself the question "Is there any good reason why I should not use MVC now?". Usually the answer is "no".
Mar 17, 2010 09:37 PM|pattioso|LINK
I guess I can understand your thinking, as a skillful developers RAD need not necessarily be "drag and drop" or "controls", therefore resistance for MVC would probably be strongest from those who turned Web developer from a VB like background.
But from a team lead perspective, "drag and drop and controls" may sound like something that can boost RAD in terms of productivity, and we can then leverage the manpower from all members in the team regardless of their strength, so having these stuffs in
MVC would definitely be a nice optional thing that helps.
Just wonder how hard it is for MS to come up with MVC based controls? can it be done by adopting it only to the view without the viewstate/postback stuffs, yet still maintaining the good model from MVC?
Mar 21, 2010 06:01 AM|gunteman|LINK
But from a team lead perspective, "drag and drop and controls" may sound like something that can boost RAD in terms of productivity
I think the key word here is"may". Drag and drop can definitely be a productivity booster in many environments, but when it comes to web development and HTML it tends to get in the way instead. The reason is simply that the complexity that the WYSIWYG, Drag
and Drop and Components attempt to hide, isn't very complex at all, and even novice developers with very basic application scenarios will very soon want access to the innards of the rendering process. Even WYSIWYG HTML editors, such as Adobe DreamWeaver, have
a very limited market penetration, simply because the things they hide are things most developers actually want access to. They're great tools, but more often than not they're used as text editors with powerful HTML support, and the WYSIWYG/Designer modes
are left unused.
While WebForms have indeed succeded in many areas, the abstraction layer that it had to introduce certainly didn't come without sacrifice. On these forums, questions like "how to include a link in a grid?" or "how to post to a different page?" or "how to
make one table row in a different color?" are not uncommon. Ask the same questions on a PHP forum and the response will be "Huh? You're kidding, right?". We're spending a worryingly large amount of time solving issues that has never been an issue in (most)
other environments and the time we were supposed to save by using a smart framework is eaten up.
That said, if someone wants to build an MVC view engine with some kind of component support and maybe even a bit of design time support, I'm all for it, but I don't think that Microsoft should introduce more complexity into the framework, only to get more
stuff that looks fabulous on the product demos but end up becoming hurdles instead.