Architecture decisions on whether to use ASP.NET MVC or webforms RRS feed

  • Question

  • User-1932979415 posted

    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. 

    Sunday, March 14, 2010 10:49 PM

All replies

  • User197322208 posted

    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

    Monday, March 15, 2010 1:35 AM
  • User-1932979415 posted

    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

    Monday, March 15, 2010 2:59 AM
  • User197322208 posted

    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

    Monday, March 15, 2010 3:12 AM
  • User-1932979415 posted

    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.

    Tuesday, March 16, 2010 9:51 AM
  • User197322208 posted

    I think the roadmap for V3 does not seem to be aggressive enough.

    What do you think it will be an "aggressive" approach?

    Tuesday, March 16, 2010 10:21 AM
  • User-1932979415 posted

    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.


    Tuesday, March 16, 2010 10:54 AM
  • User197322208 posted

    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...

    Tuesday, March 16, 2010 11:34 AM
  • User437720957 posted

    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".

    Tuesday, March 16, 2010 7:17 PM
  • User-1932979415 posted

    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?

    Wednesday, March 17, 2010 9:37 PM
  • User437720957 posted

    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.

    Sunday, March 21, 2010 6:01 AM