Yeah, Real Developers program in C or Assembler and the rest are pretenders. Variations on what ‘Real Developers’ have been……

The MVP pattern (a variation of MVC) is a very useful pattern to separate Form(no pun intended) from Function..

The idea is that a UI object should be responsible for UI and only UI. It is a portal to Input and Output and the only thing it should be in charge of is rendering.

You can test the Presenter’s logic without having to fire up the app.

MVP is highly useful in a 3 tiered web application, which you really should be doing with ASP. Writing all your data access code behind a button click is a nightmare to test and maintain.

Bob responds: I believe that anyone who is thoughtful enough to learn from their mistakes and lazy enough not to want to work harder than necessary — both traits of “real programmers” — will gravitate naturally towards patterns like MVP and MVC. What works in the other direction — towards what you call “all your data access code behind a button click” — are deadline pressures, lack of appreciation for best practices from management, and other forms of technical expediency.

Bob responds: Aaron, in a way, you can regard the code-behind to be a controller, but the fact that it is married to a single view (the form, or perhaps a usercontrol) means there is near zero flexibility in deciding what view will represent what controller.

The problem with this statement is that it assumes that such a decoupling is necessary (and possible) in most situations. How many times have you been working on a page, and honestly wished you could use a different template? Now think honestly for a moment: If you did, how much of that code behind would have simply crept into the template? How thin would that Controller be afterwards (especially after you separate the data access stuff into the model)?

Decoupling the view from the controller is one of those things that sounds nice in theory. But, none of the examples I have read actually show you how, and several sites actually admit that it is impossible (or at least impractical) most of the time.

That being said, flexibility is a great thing. However, I think that mixing code into the markup, even if it is just presentation code, is a step in the wrong direction. If there were an MVC framework in which the view was compiled down to a class, which gave you programmatic control from the controller, I would take a look at it. You could define a default view for the controller, and override it as necessary. Something like this:

this.View = LoadView("some_other_view");
// Code control of the view
this.View.dgSomeGrid.DataSource = this.MyModel.GetSomeDV();
this.View.dgSomeGrid.DataBind();

Until such a thing exists, I am not willing to give up code based access to the view for some theoretical benefits. Even if you can provide an example where you can use multiple views for the control, I would be hesitant to use it until code is removed from the markup.

Bob responds: I’ll concede I was throwing out a theoretical argument because it’s one of MVC’s selling points and it does appeal to one’s sense of design elegance. You are absolutely right, though, that it may not matter nearly that much in actual practice.

Bob responds: I never asserted that web developers shouldn’t know HTML, which would be taking my arguments to an absurd extreme. Web designers who don’t generally claim to be developers, even have to know HTML. It’s all about finding and working at the right level of abstraction, not about the fallacy of turning development into a production line operation — which I have written against extensively before.

And yes, MonoRail runs on top of ASP.NET (it’s just a custom handler), just like webforms runs on top of ASP.Net (it’s another handler associated with the aspx extension).

Bob responds: I stand corrected — thanks for the clarification!

When abstracting, the level of abstraction shouldn’t reach a point where you can’t handle at least the next step “deeper” anymore. When you use any framework, you should be able to handle the language it is written in. When you use a library for a task (e.g. XML manipulation), you should be able to work with XML manually (even if this means Notepad). Know the tools for your job, leverage them to be more productive – but stay on top of them. Don’t let yourself get controlled by them because they are actually “smarter” than you are.

The reason for this is control, understanding and most important debugging. Some people are lost when their framework has a bug, some people don’t understand the workflows even close to them because their tools do some “magical step” on the way.

Just a minority needs to know about assembler, or TCP/IP, or stacks, or memory management – but just because you have a dishwasher you shouldn’t forget about how it is to wash them by hand (admitted you don’t need to know how to potter a mug).

Bob responds: Thanks for the excellent comment — very well thought out points and great analogies.

A related example is a personal project of mine, which involves a physics simulation backend and a web frontend. I spend all sorts of time developing the physics engine, but I’ve yet to get more than one or two use cases implemented on the front end, because dealing with workflow, page layouts, input validation, etc. is just infuriating. I hate it, and if I had to do that all day, I’d find another career.

In other words, you’re right ;) Real developers aren’t protocol hackers. Real developers are those who are able to get the job done. Real developers provide real solutions, via whatever means is most beneficial to the customer, at a cost reasonable to the customer.

As for myself, I’m fortunate enough to work for company involved in network switching hardware, so I get to protocol hack for a living. Sweet!

Bob responds: You rock! In my experience not many people have the self-awareness to objectively evaluate themselves as you’ve just done — and find a place where you can be happy. Too many people with your skills and talents take positions they hate and it shows. If you ask me, we need more guys like you watching over those protocols!

The other problem is that nearly every discussion I have read of MVC covers only one form of MVC (at least for web development). I have tried several MVC frameworks for PHP and they all seem to take the following approach:
1. Build some template with code and markup mixed in, often with some sort of additional templating language, other times just using context switching. ( )
2. Build your controller. Usually has a default method that gets run on all calls to the object. Each method of this controller will be an action, associated with a URL.
3. Build a router at index.php. Take in URLs of the form http://mysite.com/index.php/class/method/id. Instantiate the class, and call the method with the id.
4. Add Models as needed.

To my mind, this approach is terrible. It is counterintuitive: to have multiple URLs pointing to the same object is just silly. It is also abstraction for its own sake. Each of those methods could be its own script. If you need default actions, the use include files. It all assumes that every page is going to be extremely simple (at least on the server end). Another supposed benefit is that you can group related tasks together. For example, you could have a user module, with login, logout and get_details as methods. OK, fine, but isn’t that what the model is supposed to be for? I get the impression that MVC was created initially for Java, in an attempt to alleviate some of the excess boilerplate. It is totally unnecessary in scripting languages that don’t need all that boilerplate. From what I understand, Rails takes the same approach, which is why I haven’t tried it. The only way this approach can work reasonably well is if each of your methods is small, with most of the code is in the presentation layer, and most of the actually processing happening on the client.

IIS takes care of the routing for you. The Designer/HTML view lets you design the view, completely free of any code (presentation code, or business logic), and because the view is compiled to code, you have direct access to every control on in the view. .Net certainly has its problems, but it is a heck of a lot better than the standard MVC approach.

Bob responds: Aaron, in a way, you can regard the code-behind to be a controller, but the fact that it is married to a single view (the form, or perhaps a usercontrol) means there is near zero flexibility in deciding what view will represent what controller.

MVC vs ASP.NET was not really the main thrust of this post; the tension between the two camps was more of a concrete example for discussing how religious wars distract from what constitutes a “real developer”. That said, I do appreciate the points you’ve raised as they are something to consider as I sort MVC out for myself …