none
MVC RRS feed

  • Question

  • Being a webforms developer since day one, I am struggling to understand how coding website using the ASP.NET MVC framework is nearly as time efficient as with webforms.  Where I could deal with all other trade-offs, I just don't understand how one could for example create rich controls such as GridView from scratch?  Would this not only require lots of time, but deep understanding of JavaScript?  I almost feel like using MVC is time traveling back time to pre .NET days.  The benefits of MVC are obvious to me, it just seems that I could never achive similar development throughput if I don't have the rich bindable control model of webforms in my toolbox.  Am I missing something?
    Wednesday, September 2, 2009 1:09 PM

All replies

  • Not really sure where you obtained your information from.

    MVC is simply a pattern that sits between UI and business logic.  Due to this fact it has no requirement to rewrite controls.

    A GridView, for example, can be, and in my opinion should be bound to by objects.  So your business layer returns a collection of domain objects, and MVC maybe maps that collection of domain objects into a collection of presentation objects suitable for bound presentation.  The controller has implementation for interface rendering, and moved that code away from code behind.

    The Controller uses business objects to get and set values on the presentation model, which is bound to whatever the control is. 

    With this in mind, and in answer to your question, yes, I think you're missing something.

    That said, and I can probably take a shot at why you asked the question - something that does need to be dealt with, in the same way as with a vanilla ASP.NET application, is the postbacks - you need to ensure that the model is only refreshed when it should be rather than at every postback.

    Believe me, MVC will not limit data throughput to the point that it would make a massive difference.  Yes, it will have an impact, but that has the age old trade off of maintainability versus speed, and connecting a data source directly to a grid isn't really going to get you that much performance increase, but it most certainly will decrease productivity in the long term.  I would recommend that you give it a try with a fairly simple example, to see what I mean.

    I hope this helps,

    Martin.
    MCSD, MCTS, MCPD. Please mark my post as helpful if you find the information good!
    Wednesday, September 2, 2009 8:25 PM
  • Martin, based on this link http://msdn.microsoft.com/en-us/library/dd381619.aspx, the article states:

    Because ASP.NET MVC does not maintain state information by using view state, you must find other ways to manage state information, if you need it. In addition, server controls that rely on view state and postback will not work as designed in an ASP.NET MVC application. Therefore, you should not use controls such as the GridView , Repeater , and DataList controls.

    If anyone can point me to a sample that emulates the same functionality as a GridView using ASP.NET MVC framework it would greatly help clear up my concerns.  Thanks.
    Wednesday, September 2, 2009 11:39 PM
  • Hmmm...

    I didn't know that, so out of interest, do you know what happens?  What is the view state used for, as the data should be coming from the model, so is stored independently.  I'd guess that some of the data from the control is stored in viewstate instead of being stored in the model - in which case, maybe it is a case of setting those values in the model when they change?  The implementation that I have been involved with, with MVC outputs using simple code behind to display the data, which would be why it works, but not the smartest solution.  Id have to say, you're trying to shoehorn an architecture into a technology, I would suggest that if the controls cannot work out of the box, but you want them to then you need to look elsewhere.

    MVC definitely won't have performance issues, but isn't really appropriate for all scenarios, in fact from what I've seen of it, it should be better stated as only being relevant to a few, i.e. you would have to work around it to get it to do what you want it to.  This undoes the point of using it, so I would not use it.

    Apologies if I sent you in the wrong direction initially.  My experience of MVC is that there are better choices to be made for scenarios, and you need to ensure you pick the right one, rather than assuming MVC is it.

    Cheers,

    Martin.
    MCSD, MCTS, MCPD. Please mark my post as helpful if you find the information good!
    Wednesday, September 2, 2009 11:59 PM
  • No problem Martin, it's a learning experience for us all.  From what I understand you can use the GridView for the initial rendering of data, however the doPostback JavaScript etc. will obviously not work.  One of the most obvious benefits of webforms IMHO is the ability to drop a rich control (ex. GridView) onto a webform and have a fully functional (sorting, paging, ajaxed perhaps) control without having to a) write the output (ex. For loop for HTML generation of rows) and b) having JavaScript (not sure if necessary) to create functions that would post back to the server with the need to page/sort etc.  I completely agree with you, not all tools work for every scenario.  I am just trying to understand how I would go about creating a line of business apps with similar efficiency as I currently do with webforms.  In many ways I see MVC as going back to legacy ASP (at least from the view perspective) days.  I feel that the object oriented rich controls that webforms provide are a huge time savers, I don’t need to emit my own HTML, the controls will do that themselves (not only that, but they would do it based on the requesting browsers capabilities).
    Thursday, September 3, 2009 1:11 PM
  • Hi,
    You are absolutly right.
    MVC should only be used when you want to build different views on same business layer/data layer.
    E.g. in yahoo mail, they are providing facility of using either simple legacy technology based webpage or latest Ajax based mail interface, keeing the below layers same.
    There it makes sense, but not makes sense some generally developed enterprise application until you have to provide different interfaces to different customers as a product not as a application.

    MVC is kind of struts in java world but not everybody uses it.
    Performance would definely got to hit, though not very much by using MVC as it has a level of indirection instead of direct binding.
    As per my knowledge, you can't use toolbox controls meant for regular webforms.
    So ultimately you are losing some perfomance, adding much effort by using MVC however if you require flexibility provided by MVC, do go for it.
    Like in my previous project, it was a SaaS application to be hosted on clud which would serve multiple client with different views.There MVC did made sense.

    Hope this helps

    Cheers
    TA123
    ------------------------------------------------------------------------------------------------
    Please mark this as answer if it helps you
    Thursday, September 3, 2009 3:09 PM
  • TA123, thanks for your reply.  I think I would almost rather go down the MVP path, which (based on my current understanding of the pattern) provides very similar functionality (being able to swap views).  One huge benefit is that it is MVP is just an abstraction of ASP.NET; therefore you still get the benefit of rich controls, viewstate, etc (note: I have no working experience with MVP). It seems to me that if a team chooses to go down the MVC path, then it ultimately requires people that will write and maintain views, those people should have strong HTML/JavaScript skills.  This is not all that important with webforms as one can create an extremely capable website with hardly any real HTML or JavaScript knowledge due to the amazing abstraction model provided by the toolbox.
    Thursday, September 3, 2009 3:31 PM
  • You are right.
    MVP would be more suitable with all the benefits.
    More can be found at for making suitable decision here.
    http://social.msdn.microsoft.com/Forums/en-US/modelingandtools/thread/eecc7b01-cee0-4c20-9086-b1c4cafa6709

    Hope you are not working in service industry for another company where you have been asked for using MVC.

    Cheers
    TA123

    ------------------------------------------------------------------------------------------------
    Please mark this as answer if it helps you
    Thursday, September 3, 2009 3:44 PM
  • Hi Srigopal,

    MVC link doesn't work.

    Sam.

    Friday, October 26, 2012 8:15 PM
  • Sorry I lost couple of samples so I am re writing and updating the article, that's why I have unpublished that.

    Now it is available try this link http://code.msdn.microsoft.com/Design-Patterns-MVC-Pattern-aa79900b

    Please feel free to get in touch with me for any questions.

    Planning to write at least 20 + samples so that it helps beginners to pick up fast.


    Thank you, Regards, Srigopal

    Saturday, October 27, 2012 2:19 AM