Sho Kuwamoto

Let me caveat all this by confessing my general tendencies as a programmer and engineering manager, which can be summarized by one word: laziness. And as a lazy programmer, I'd never really gotten into MVC in desktop GUI programming. For me, separation between view and model was the important thing. Separating out the controller from the view seemed to be more trouble than it was worth.

MVC actually makes sense for the HTML-based world, because there is a physical separation between the view, which lives on the client machine and the model, which lives on the server machine. Logic to respond to user events usually needs to be handled on the server. Does it make sense for the model to take care of these events? Of course not. Ergo, you need to separate out the controller logic from the model logic.

There are nasty things about this approach as well. You often see architectures in which a single controller handles all of the "actions" for the entire application. I see this as a necessary evil, not a "good thing". The world of the giant switch statement is exactly what we wanted to avoid with OO programming, right?

With Flex, you have a powerful engine on the client that can perform complex logic and directly access Web services. Because of this, the forces that propelled everyone to adopt MVC need to be reexamined.

For some applications, it may make sense to separate out controllers for the application. And for certain components, it will probably make sense to use the MVC pattern for that component just like in the Smalltalk days. But for the majority of apps, I think that separating the view from the model is the big win, and in most cases, the "model" part of your application consists of services that live on another machine, so that separation is something that you have no choice about.

Ok. Flame away!

P.S. Heidi, our engineering manager, came back from sabbatical last week, so my days are becoming a little less hectic, hence this post. *whew*!