If you’re going to provide RAD for ASP.NET MVC, change your thinking hat

ASP.NET MVC is not new. Ignoring the pattern for a moment, the way things work dates back to the days of CGI’s and ISAPI’s, where you had to role out pretty much everything by hand. You would get your data, format it and send it back to the browser, producing HTML. It wasn’t easy, but you did have one advantage. You had full control.


Gradually, tools starting to emerge to bring some sort of “RADness” to this kind of development. I in particular, used a technology called WebBroker from Delphi; we had Actions, PageProducers (replaced tags at runtime in an HTML template) and our data. Same concept as ASP.NET MVC, same concept as MonoRail, and other frameworks. Despite still having to do a lot of things manually, it did prevent us from having to write repetitive and tedious code in many cases.


Up to then, you had one requisite to develop web applications: you had to understand the web and the technology behind it.


Traditional ASP.NET or ASP.NET WebForms came around, among other things, to solve this problem: allow the non-web developer to leverage their existing knowledge to port their applications to the web. This meant not having to know much about web technology and at the same time. ASP.NET WebForms provided a powerful approach to web development: the concept of drag-n-drop that existed in WinForm applications. You could now take a control, drag it across to a form, set some properties and away you go: in minutes you had a web interface without having to even know what HTML meant.


Now, I’m no fan of ASP.NET WebForms. Actually that’s not entirely true. I hate it, but I still admit that for some it has it’s attractiveness and has solved problems for many people and put food on the table for many developers. So it has it’s place and will continue to live on.


I’m also not alone. There are others like me that don’t like ASP.NET WebForms. As such, when ASP.NET MVC came out, it gave us another technology, based on the ASP.NET stack, to  develop web applications.  Ignoring many of the differences and advantages it has over traditional ASP.NET, above all, it gave us control. As I always say, it put the web back into web development.


As developers started to embrace this technology, questions started to arise about what kind of support there would be in terms of controls. Naturally, third party component vendors, those same ones that were providing support for traditional ASP.NET components, were being asked about this too. All those that I spoke to pretty much said the same thing, let’s wait and see. And it’s completely the right approach. There’s no point in investing a large amount of time and resources into supporting a new framework if you don’t know what the success of the framework will be, both in adoption, as well as commitment from the company behind it, in this case Microsoft.


Now that ASP.NET MVC has been released, and there is a growing number of developers moving over from traditional ASP.NET, some companies are starting to develop a limited number of controls for ASP.NET MVC. I’m guessing that some of these companies are dipping their feet into the MVC waters to see what kind of success their components might have, before taking the big plunge.


I’ve examined a few of these components. I’m not going to mention any names or give an examples, but suffice to say, that up to now, I don’t like what I see. And the reason is simple. Most of them are taking the wrong approach. They are thinking with their WebForms hat on. However, since there is no visual designer, they are using an immense amount of markup with custom tags to define their components. And many are mixing data, behavior and appearance in these markups. The problem with this approach is that it’s going down the same route that many ASP.NET MVC developers left behind from by moving away from traditional WebForms: rich-intelligent-know-it-all controls. I’m not going to show any code since I don’t want to single-out any specific control/company, but sample applications for many of these exist and you’re free to examine them for yourself.


To summarize, trying to bring the same RAD controls that exist in WebForms over to ASP.NET MVC might not necessarily be correct thing to do. This is a different way to doing web development, a different mentality. And in my humble opinion, I think that this might backfire, since MVC developers mostly will not be too keen on this type of solution, the adoption rate for the components will be low and the component vendors behind them will throw in the towel.


5 thoughts on “If you’re going to provide RAD for ASP.NET MVC, change your thinking hat

  1. Sebastian Gingter

    Hi Hadi,

    I’m not totally with you. Yes, having full control is in general a very good thing. But when you know about html and ‘the web’ in general, you can also use ASP.NET WebForms and have full control about what the browser gets (in html and JavaScript). And you can use a lot of controls, that are already there. Using MVC you are forced to do all that by yourself.

    How long would it take you to build a grid with paging, filtering, sorting, re-ordering of columns, removing and adding columns and excel export of the current grid’s content using MVC? Oh, I forgot skinning, because several customers of the application want to use individual layouts. I’d say at least several days. There are at least three grid controls out there for ASP.NET WebForms you can simply take out of the box, put it on your form and don’t bother about functionality.

    If you can live with that bit loss of control and performance in respect to the gain with full featured already-ready controls, I know few that would pay for developing these things once again on their own. So I’d say it depends on what you really need. Having full control is nice, but do you really need that always? Having a control by hand that just works is enough sometimes.

  2. Hadi Hariri


    It’s not only about loss of control, it’s about the mess that these controls create. How long would it take it an subjective question and it depends on what you consider your ROI to be. Having said that, did you look at jQuery? What you ask it would take me 10 minutes to do cleanly. Also, there is a mis-conception of MVC of having to do it yourself.

    I think I’ll write a follow-up blog post in regard to your questions.

  3. ram

    i am waiting for that sample which was supposed to take 10 minutes to implement.

    i guess the world is full of outspoken opinions…but how about you do some critical thinking before you publish something and make a fool of yourself.

    my point is: not every developer is intelligent enough to muddle with the gory details of assembly language…hence came RAD development tools…and business love it.

    so get off that ivory tower…and think about cost involved if you want to go back to building gui applications using c++.

  4. Hadi Hariri

    Hi Ram

    thanks for your feedback. Sorry that I wasn’t aware you were waiting for a demo from me.

    Unfortunately it seems I didn’ t get my message across clearly. This isn’t about RAD or not. It’s about how things are done, based on the context.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s