ASP.NET MVC: A New Framework for Building Web Applications

The Discussion

• 

  Hi Phil - As per your request for er... requests.  I would like to hear you talk about you and your teams latest thoughts on component development with ASP.NET MVC.  I am not a component vendor.  However, on Classic ASP.NET projects have often built components that are used by multiple teams on multiple projects.  It would be cool to hear the story on this from the horses mouth.  Can offer cocktails on The Standard's roof in return.
  
  

• 

  - Discuss the different options we have for posting form data.
  

  Create(Product product)
  Create(FormCollection form)
  Create(string name, string value)
  Create() - access Request.Form...
  

  What are the benefits of each and especially WHEN and WHY we might want to use one over the other.  
  

  
  - Although the talk is not about TDD specifically, I'd love to see more about common scenarios and how to test them.
  
  - More information on the different types of action filters we can implement.
  
  - General solution layout best practices, naming conventions, code organization etc.

• 

  I can't imagine why anyone would want to use MVC .NET.
  
  Complicated MVC never works well in the real world.  It's the reason I moved from Java to .NET a few years ago.
  Projects are never done on time, it's hard to maintain, large learning curve for a new developer coming in and no one ever wants to work on the code besides the person who originally wrote it.
  
  
  I'll probably go to this just to hear the reasons why and laugh.

• 

  I disagree. Your negative experience with the Java MVC frameworks shouldn't be a condemnation of the MVC pattern. The pattern itself is valuable for web applications even in the "Real World". The popularity of Ruby on Rails and DJango is a testament to that. 

  
  

  ASP.NET MVC is intended to be a simple to use framework for developing web applications. It's not for everyone, for sure, but I think you'll find that it isn't overly complicated and is easy to learn.

• 

  I’ve been developing multi-layered web applications(web forms & APIs) now for 8 years and in my experience the MVC pattern is hands down the best choice for architecting an extensible, maintainable and highly isolated solution. Prior to the ASP.NET MVC framework, I was using the UIP application block w/NET 2.0(I’m serious) that Eugenio Pace and team had put out a guess about 6 years ago? The clean separation of layers & responsibilities throughout the application architecture just makes perfect sense to me. When MS announced they were introducing the ASP.NET MVC framework I knew something great was on the way…and thus far I have been more than impressed the framework, community involvement/support and the team’s responsiveness to the developers currently working with the MVC.  
  
  

  I’m currently working on implementing a solution for my employer that makes use of the ASP.NET MVC framework to expose a REST based API for consumption by internal and in the future external clients. We are currently also making use of the following MS Enterprise blocks:
  
  

  1.       Validation

  2.       Logging

  3.       Exception Handling

  4.       Caching

  5.       Data

   

  Thus far everything is fitting together very well under the MVC ‘hood’ with the use of some other design patterns such as Façade & factory (abstract) including the ASP.NET membership model. Once the UI component of the application is built, I’m sure we’ll make use of the JQuery framework as well.

   

  Regarding what I’d like to see at the presentation…
  
  Ditto on the previous suggestions:

  1.       More information on the different types of action filters we can implement (or that are on the way).
  
  

  2.       General solution layout best practices, naming conventions, code organization etc.
  
  

  3.       TDD examples, how-to's - I realize there's a lot of information available on this. However, sometimes seeing a demo(w/Preview 5) really drives the message home.

  Perhaps some of these topics could be addressed or discussed:

  1.       The use of the MVC framework for a REST application that could serve as both an API as well as a data source for UI application(sound familiar?). I believe Rob Conery had an article touching on this topic.
  
  

  2.       The concept of the use of the standard verb/action methods typically associated with REST…should we stick to using the 7 defined actions? Perhaps reason why we should or should not?

  1.        Index

  2.        List

  3.        Show 

  4.        Edit

  5.        New

  6.        Create

  7.        Update

  8.       Delete

  3.       Routing best practices & how to configure routes in a config file of sort?

  4.       What not to do when developing with the MVC…perhaps lessons learned from the team?

  5.       A road map of the framework…I realize a lot of people have been hounding you guys about this. But any further insight you could provide on when we could expect a release date would be greatly appreciated!
  
  
  Looking forward to conference!
  
  Cheers,
  Kyle

• 

  Don't forget to submit evals!!! And remember, higher numbers are better. To the person who gave me all 1s, I hope that was a voting error. Otherwise someone here really doesn't like me.

• 

  Hi Phil,
  
  Very interesting presentation you did at PDC2008.  Is there a URL where I can get the source code of your presentation (with the usual disclaimers)?
  
  Thanks

• 

  Source will be posted here soon.

• 

  Something wrong with the video, its not loading anymore.

• 

  Please make an iPod (MP4) version of this video available.  Thanks!
  

• 

  Hi Phil.
  Could you also share your visual studio style/theme please?
  My eyes feel really comfortable with those colors and fonts settings
  Thanks,
   Luca

• 

  Hi Haack,
  
  The one that interest me about this MVC is the SEO.
  I was wondering whether it's possible to code in web form style, created aspx files in many sub folders, and remap the IIS to treat .html as aspx.
  
  What do you think?
  
  Thanks
  
  

• 

  @Haacked: Hi Phil,
  I'm in the process of starting a major project and still debating what platform to use (WebForms versus MVC). Let's assume this site will have 100,000 users.
  I was wondering if you could tell me what is the best practice to keep the user known across pages. I don't believe it's the Session, and I don't want to use the Membership database since I already have my DB and don't need another one.
  I'm not too clear if the call HttpContext.Current.User.Identity.IsAuthenticated needs a Membership Database underneath or how does it remember the current user? Is that by the means of a cookie?
  If so, is it "bad" practice to create my own cookie and put my own data, as long as I encrypt it before saving on the Response.Cookies ??
  Salut from one Fil ...to another Phil