So why exactly do we want to move away from Controls to MVC?

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.

7 thoughts on “So why exactly do we want to move away from Controls to MVC?”

  1. MVC is great for web applications. Control’s strength is also their weakness – they’re isolated little islands, that have their own markup, own understanding of web best practices, etc.

    Controls make great demos – Microsoft has been demoing dragging the database and displaying the Northwind database before I even knew I wanted to program. However in real applications you always end up hating that dragged datatable.

    This might not be the best argument, but look at the popular web frameworks in other languages: php, python, ruby, java – they’re on to something.

  2. It seems as though a seperation of concerns is also paramount in the design of an MVC based approach. Take, for example, the page and control based lifecycles of ASP.NET. Pretty much, look at how much do you go through before you can execute one line of business logic.

    Not to mention having to memorize the lifecycles to begin with. 😉

    This seperation also allows for a more REST based approach, where resources are available in different formats (think SOA and web services) and the requested view drives what is delivered to the requesting client. Routes are also clearly seperated. You know longer hit “pages,” you hit routes.

    The focus on the model (even more so, the domain model if you take a DDD approach) over pages and controls is important to me. It’s tough to dig through lots of page cycle events before finally being able to request something from the domain.

    And yes, testability, but more so TDD and BDD where you start with the tests (or specifications) and drive your implementations from those “requirements”.

    As far as controls based argument, I think ASP.NET probably has MVC beat currently, but that might change soon enough?

    2 cents. Thanks.

  3. I love ASP.NET MVC that is the best thing from Microsoft since .NET was released. I was driven to .NET because it was by far the most powerful XML/XSLT transformation engine together with C#. But I simply never understood what is so great about ASP.NET. I understand that for the application programmer especially for Windows programmer controls are easy and nice but it sucks to be a webdesigner in ASP.NET world because you don’t have full control over html. It has got a lot better in .NET 2.0 but it is still bad.
    I think MVC solves this. But like ScottGu and Hanselman says MVC is not for everyone and it is not here to replace ASP.NET.
    But for me MVC is a natural step from XML/XSL transformations especially since I can still use XSL for templating engine in MVC.

    One thing is intresting though, if MVC on .NET has remotely same effect as Django and Rails is forming on the “other side”. What will be the future of CMS like Sitecore?
    I don’t see how MVC and Sitecore (or any other CMS) can work together do you?

  4. Hello Alexey, Nelson and Jukka-Pekka,

    I still do believe controls are great. Why? They are as complex as any Markup Language is. An old colleague of me ever told me that a Domain Specific Language such as ASP.NET is as complex as the domain itself.
    I don’t see how this could be made easier with the MVC model. I only see a lot of work for getting used to the pattern, a lot of less readable code(be honest, stuff like attributes above methods are not pretty and easy to understand). And beside of that, MVC is only interesting to use when you’ve to reuse the data very often. Otherwise writing or generating Model, Controllers and Views are just to many steps. The form support itself is ridiculous, for those circumstances you need a control model. Or maybe you should generate a Model for this once again?! That would mean that instead of making stuff easier, you’re just generating more and more code. Which does make your codebase more complex. Especially because the generated code is the place where you want to add your business logic.
    Beside of that, how do you guys think about generating forms on the fly? Ever heard of a changing Model on the fly?

    Jukka-Pekka makes it even more interesting. Yes I’m sure there will be a future for CMS’s. In the world of CMS’s there’s a general bigger challenge then just techniques. This challenge is called ‘organizations’. Simplifying processes, making marketing people more effective, etc.
    When you look at it from a technical perspective, so far MVC has only been working with database date. Typically Microsoft. MOSS is also only database data. Texts and blob. But there’s way more in this world. For example relations between content, either impliciet(taxonomies) or expliciet(e.g. links in content). And as long as we’ve to help people in making technical stuff usable for the end-customer, there will be a challenge for CMS Vendors. 🙂

    – Alex

  5. MVC is terrible for web applications. By applications I don’t mean websites which contain a form or two, I mean applications which are organised like normal desktop GUI applications and behave like desktop applications. For web applications you need support for components/controls and you want all of the HTTP/HTML stuff between the browser and your application to be handled automatically as much as possible. You want state management and events and the same programming model as normal desktop applications. This is the model which makes sense for programming applications. This is the model which has evolved since the early 80s to where it is now. Work using GUI components and events, that is the right level to be working on, not HTML and HTTP.

    That being said, MVC is a reasonable way of organising your project if:

    * You must follow a graphic design from a designer which is delivered as HTML+CSS.
    * Your forms are simple and don’t need complex UI controls.
    * You are creating a page based form for a web site.
    * You just want a step up from the tradional PHP/ASP/CGI style of request/response programming.

    But don’t try to make applications using MVC. It doesn’t offer the support you need.

  6. If you want to make a desktop application, maybe Winforms or even Silverlight, Flash and the Java Applet would be better suited.

    WebForms does a reasonable job of abstracting the Web away for development, and that’s it’s strength and weakness. To make to best of the web you really have to embrace it.

    MVC allows for TDD, WebForms is a pain to test. Even desktop apps could benefit from an MVC approach.

  7. @Simon:

    MVC is an apt pattern for the web. It fits it much more nicely than the leaky abstraction of a stateful platform on a decidedly stateless protocol. This breaks down quickly, and you spend more time dealing with issues relating to this leaky abstraction than actually writing for the web, which is what I think we should be doing.

    ASP.MVC doesn’t support server controls, but it does have a ton of flexibility in how you compose a view.

    The web isn’t the desktop. We shouldn’t pretend that it is, and we shouldn’t write applications as if we were running on the desktop. Program to your platform, and you’ll reap the benefits that it has to offer. Put on rose colored glasses and pretend that you’re writing for the desktop and be certain that you will face performance and/or usability problems along the way.

    ASP.NET MVC is a back-to-basics platform that takes a few key things right to its core:
    * testability
    * single responsibility
    * full control over URLs, HTML, CSS, Javascript integration
    * easier ajax integration

    Lastly, also consider that ASP.NET MVC is still in its infancy. There are rough edges, sure. But it’s a breath of fresh air in comparison to WebForms, in my opinion.

Comments are closed.