[Ed. note — I posted this last year as I was learning the Flex framework. Since then, I’ve built a few Flex projects, and for some of them, I found myself using MVC, although I typically use more of a SmallTalk-like MVC pattern rather than a struts-like FrontController. Another data point is that since last year, I’ve talked to lots and lots of people who have tried Cairngorm, and 95% of them seem to like using the FrontController pattern so take my opinions with a grain of salt. –Sho, Apr 2006]
Recently, I’ve been thinking about the appropriate way to wire up Flex applications, and I’ve come to the conclusion that… drumroll please… MVC is probably not needed for most RIAs. Or more specifically, application of the FrontController pattern is probably overkill for the vast majority of Flex apps. (I know that Steve and Ali are going to disagree with me violently…)
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*!