Funny, check this post on From handling by Scott Guthrie. Why exactly do we want to move away from the ASP.NET Control model to MVC? To write more code? Even creating a form becomes harder. Wasn’t MVC designed to display… Models? I might be to tired right now to understand this. But I can’t see a clear reason for me to go to MVC Form handling. Everything described was implemented together with LINQ to SQL(or Entities) in 10 minutes, with some generated classes(the LINQ stuff) and 20 lines of HTML and ASP.NET controls, and another 20 lines of boilerplate C# code. Yes I tried it.
I’m missing the clue. Are you still on track? Correct me if I’m wrong, but isn’t making this model development once again more sophisticated? I can see the purpose of MVC for large amounts of data. For a year now I’m writing notes to myself on how to create a DSL for generating this model out of Sitecore. But in ALL my notes, I’ve never mentioned form data. And the funny thing is, in this example you can only use 1 specific url to post your data too.
I don’t want to to Sitecoreish, but one of greatest things about Sitecore is that I can place my forms anywhere and reuse in on any page… I’m getting more unsure where Microsoft has designed the MVC framework for. Scott Guthrie says at the end:
Important: If you don’t like the MVC model or don’t find it natural to your style of development, you definitely don’t have to use it. It is a totally optional offering – and does not replace the existing WebForms model. Both WebForms and MVC will be fully supported and enhanced going forward (the next release of ASP.NET WebForms will add richer URL routing features, better HTML markup/client-side ID/CSS support, and more). So if after reading the above post you think “hmm – that doesn’t feel natural to me”, then both don’t worry, and don’t feel like you should or need to use it (you don’t).
Let’s say it in another way: I’ve been interesting in the MVC model since the first moment. I hoped it could improve productivity for you guys out there, writing div’s and lists on daily base. With the identical data. So far it seems to be only designed for Database driven applications, similar to phpMyAdmin, but less flexible. That’s not where I was looking for. Hopefully Scott gives us a better impression next time, right now I’m completely unsatisfied with it.
For those who mention that MVC will help us in test driven approaches. You’re 200% right. But… a test driven approach can only succeed when you create software to reach requirements. You can’t write a Unit test in part x of the application when a Unit test in part y of the application tells you the opposite. One of those will fail, certainly. The requirements of our customers are quite clear in general: we want flexible websites which can be controlled from a CMS. So far that seems to be impossible. So a test driven approach doesn’t make sense at all.
Some recent news from our R&D department proved me that I’m not 100% right in this post: we’re trying to be as less dependant of the HttpContext as possible. We’re working on ways to let Sitecore run outside of the HttpContext. No ETA’s and product announcement from me, just to inform you, that we take your requirements(even when it are quality or development requirements) serious.
You might think I’m to critical, guess I’m. But I’ll give MVC, when it will be released, another serious change. Our R&D team believes, like I do, in the pattern itself. We have to look further into it, how and under which circumstances we can support it once released. That will definitely be a nice challenge.