The Model-View-Controller pattern is one of those things in programming life that looks really sexy on paper, kind of like Charlize Theron, but then when you see it implemented it ends up looking a lot more like Charlize Theron in Monster.
Or at least that’s what it looks like in the .NET world. And maybe .NET and it’s code-behind paradigm are to blame for the uglyness, because the clear delineation of responsibilities becomes blurred. Some people actually think of the code-behind as a controller, and some people do not. I find myself questioning: is the code-behind really a controller? If not, can it be used like one?
If you look at the code-behind as a controller in a MVC pattern (and I’m not saying it is), then there might be some value to .NET 2.0 partial classes. The problem is that I think the designers got the partial class implementations reversed.
When you create a new view (Form/UserControl) in the designer, VS2005 automatically creates two partial classes: the form class, and then a form.designer class that contains all of the designer generated code. The image at the top of this post shows two classes: CustomerView.cs and CustomerView.Designer.cs.
The objective here is to split designer generated code from programmer generated code. Sounds like it might be useful, right? But the implementation is backwards. Clicking on your form class in VS2005 (CustomerView.cs) takes you to the form designer in VS where you can view your form, edit properties, drag-and-drop components, buttons, textboxes, etc. But all of the designer generated code is in the other file (CustomerView.Designer.cs).
It seems to me that the developers got it backwards when they designed this. The CustomerView.Designer.cs file should be the file that is clickable to launch the VS designer/form editor. The CustomerView.cs file should be the file the programmer codes in. If you did it that way, you could then have a pseudo MVC pattern at work. All of the actual UI code would go in CustomerView.Designer.cs, and the Controller code could then go in CustomerView.cs. Heck, you should even be able to setup VS2005 to do this automatically with proper naming: CustomerView.Designer.cs and CustomerView.Controller.cs. Hook up your Model and you’re good to go.
Of course, none of that addresses the issue of reusable controllers, which is why you really implement MVC anyway (so you can hook it up to a Windows Form or an ASP.NET page). But at least in a .NET code-behind context, with partial classes, it would make more sense.