I just read through a blog post by Sho Kuwamoto titled MVC considered harmful, and began typing a comment that quickly became a small essay, so I decided to post it here instead. While I don’t agree with Sho’s idea that MVC is not needed for most RIAs (I think the concepts are valuable for virtually any kind of Flash project, RIAs in particular), I also didn’t agree with some of the more zealous comments about the sanctity of design patterns. Here’s my take on the whole thing…
One of the things I try to emphasize with developers is that the only absolute in programming is that there are no absolutes. A lot of developers get trapped, either by becoming a pattern zealot and wasting a lot of time trying to code to patterns, or by disregarding patterns completely (because they are too hard to understand, require too much forethought, etc).
Patterns are architectural heuristics. Understanding them should widen your solution spectrum, not narrow it. They provide you with proven ways of solving a specific problem in programming. The reality is that you will rarely encounter that specific problem in the wild, but you will encounter variants of that problem – as such you must be flexible enough in your coding “philosophy” to adapt patterns to suit situations. You must code to the scenario, not to the pattern.
Fact: No one codes Flash using pure MVC. Many developers code Flash using variants of MVC, but no one uses a pure implementation – because there is no pure definition anymore. MVC is over 25 years old (1978), and it’s definition has been blurred over time as developers massage it to work with modern application constructs. The most obvious examples of this are the updates to the pattern for Smalltalk in the late 80s and early 90s, then again by the Group of Four in 1995. One of the first things you will realize if you read up on MVC (and patterns in general) is that everyone has a slightly different take on them, and this is a good thing – it means developers are adapting a heuristic to work in their environment.
Patterns also provide a foundation for communication between developers. If a group of developers all share knowledge of MVC, it is far easier to discuss the architecture of an application that implements MVC because a certain structure can be assumed by all participants. One must remember though that it is a foundation, and we can build on it by qualifying our usage of patterns: “This application implements MVC, with the caveat that…”
Flash in particular requires flexibility, because most projects are not your run-of-the-mill form based applications, and patterns often do not apply perfectly (but they certainly DO apply).
In conclusion, understanding of patterns in their pure forms is essential for any modern developer, regardless of the language they are using. This understanding must be tempered by common sense, and willingness to adapt that knowledge to achieve concrete goals. A programmer that understands design patterns is an educated developer, but a smart developer knows how to implement and adapt those patterns to real world situations.
Pattern zealots might sound smart, but they are not much better off than developers without any understanding of patterns at all. Both are narrowing their solution set through their ignorance.
I’ll leave you with a link to a quote from Children of Dune, which I think sums things up nicely.
Thanks, Grant. Despite the title of my original post, I think I agree with your post. Of course, it’s not as fun to write an article titled “MVC is sometimes useful and sometimes not as useful, depending on the situation.” 🙂
When you create controllers for your Flash-based apps, what level of granularity do you have for the controller? Is there one controller for the whole app? Does it respond to every single user event?
Sho, I hear you… sensational headlines sell, but they can land you in the pot occasionally. 😉
Some definitions of MVC call for a single controller, supporting multiple models, each with a view. Obviously, Flash apps almost never work like that – Flash MVC is really distributed MVC, often different views have their own controllers, and views are all managed by a master state management controller. Of course, components in Flash almost always combine view and control, as you suggested in your post. Different requirements dictate different implementations, knowing when to bend the rules is the hardest thing to learn in programming.
State management is something that I believe strongly in. Is it a controller or part of the view? State management doesn’t communicate with the model, typically, right?
MVC says that the entire application state is supposed to reside in the model. However, many applications maintain application view state in the controller, and the data state in the model. Just another example of the common variances from true pattern implementation that you see in programming.
Thank you Grant and Sho for a good discussion, I haven’t used flex yet, so I can’t comment on implimenting MVC there. I do use it often in Flash, though.
The most important point for every developer is, from my point of view, understanding the problem that a pattern solves, not learning by heart the implementation of the pattern.
When you are able to see that there is a bad smell in your code, that is a huge step ahead.
If you have some understanding of patterns, it is easy to find the one that could solve the problem, and adapt it to your specific problem. There are a lot of books where you can find the implementation details.
I also don’t believe in monolitic implementations of patterns, and maybe MVC is the best one to show it. Take the Cocoa MVC, for instance, with its heavy controllers, a pure J2EE MVC, or a strict MVC implementation, and they will look really diferent. I just depends of what you need.
MVC, and StateMachines are orthogonal concerns (depending on the app each tier may have it’s own StateMachine. The differentiation typically is in MVC the model state is persistent, and survives a many to one relationship (e.g. a bar and line graph both using the same data.) where as state machines are useful for runtime states.e.g logged in, not logged in.
Both exhibit heirarchies/graphs and granularity, e.g. a toggle button on a nested form has state and could be modelled as a MVC+ toggled on off state where each state is a class. Or it could be just a single class comingling those concerns and variable.
Nice post Grant. I think Sun’s appropriation of “MVC” for Swing and Web applications was an unfortunate choice that meant the C in MVC could mean very different things in different environments: Smalltalk, Swing, Web apps…
I think it also diluted the details of the MV part of MVC which seems to now represent a basic idea rather than a design pattern: separating model and views. It used to represent a specific publish/notify pattern that Colin Moock does a great job of describing in EA2.
I only like to talk about MVC now when there is something resembling Smalltalk MVC triads at work and controllers are required to move messages between triads. Otherwise I think the GOF book got it right to not include MVC as a pattern.
When people say they are using MVC I take that to mean they see their application as being organized somehow into three parts that can be worked on separately:
1. data and business logic,
2. presentations of that data, and
3. some sort of event management and propagation system.
I donât really think MVC means much more than that anymore. Consequently its value in discussing real-world designs has become suspect.
Yours truly,
-Brian
Hi guys.
I’ve been meaning to find some literature on designs patterns and possibly examples on how they would be implemented in flash. I believe, as Grant suggests, an understanding of how to approach a problem means youâre halfway to solving it without writing a single line of code. Do you have any recommendations on books and/or URLs?
James
Hi James,
If you want to see patterns implemented in Flash I would start with Moock’s essential actionscript 2.0 (eas2) http://www.moock.org/eas2/
He does a great job of setting you up for OOP in Flash and then taking you into implementing some patterns.
Then the GOF book:
http://www.awprofessional.com/bookstore/product.asp?isbn=0201633612&rl=1
Yours truly,
-Brian
Thanks Brian.
James.
James,
If you find yourself having problems understanding the world of Patterns, I would highly recommend you looking into the Head First Design Patterns book.
You can find it here:
http://www.amazon.com/exec/obidos/tg/detail/-/0596007124/qid=1124823686/sr=8-1/ref=pd_bbs_1/104-2484182-2684762?v=glance&s=books&n=507846
The text seems somewhat silly if you judge it by the cover, but it was THE vital step for me to apply OO practices to Flash applications. It is written in Java, but the code samples are effective and strikingly close to Actionscript 2.0
I totally back up Seth Root’s recommendation of Head First Design Patterns. The book if you page through it is silly but if you read it the way it is supposed to be read, you will see into your code further down the road and into the future and figure out that there is at least one certainty and that is that the code will change.
Learning about design patterns and OOA/D will 1) prepare your code to handle that inevitable change by decreasing the probably that it will break and 2) it will provide you with a broader vocabulary to express those parts of a program and be able to communicate it with other developers.
The book is best aimed not at novice ActionScripters but those who are intermediate or advanced. Itâs for those who want to make better use of AS2.0 and stop coding themselves into a corner by coding to concrete classes instead of interfaces. Moockâs take on design patterns left alot to be desired but I have to admit that he opened the door for me to learn more about patterns and how it can make life easier developing in Flash.
Thank you Seth and Mark for you’re reccomendations.
“Patterns also provide a foundation for communication between developers. If a group of developers all share knowledge of MVC, it is far easier to discuss the architecture of an application that implements MVC because a certain structure can be assumed by all participants.” – Totally agree with you. I believe the MVC opens a lot of opportunities for code reuse and organization, and it’s very important to share knowledge and experience. It was nice of you to post your article here instead of submitting a comment. I enjoyed reading the discussion on this page and I’m thankful for the useful information I found.
I’m just wondering why people aren’t using MVP, although similar to MVC, its more suited to flash no?
I agree and disagree based solely on the scenario of the models use, and the program at hand. If OOP is geared towards scalability then even the most simplest program can benefit from a pattern, because the key feature of any pattern is foresight. Having the ability to perceive future additions to the current application. The MVC I won’t state is the backbone that should always be used, but I would never count it out as something that is merely over head.
The main issue is that these patterns are made up of the bounds and limitations of the API by which a programmer was coding. This is one of the biggest pitfalls for any developer to overlook. Not everything can be migrated from one program to another, without changing or modifying its original structure. This itself changes the pattern allowing a new one to emerge. So who is to say any longer what IS right and what IS wrong?
Ten developers can come up with their own solutions to solving the same problem. And depending on the scenario, there is bound to be overlap, but not line for line likeliness.
But for those who want a break down of the mvc I have posted a part 1 of 2 explanation of the Model
http://flashplaya.net/news/?p=79
Hi Grant,
I agree that you have to keep in mind the design patten structure, but adapt to whatever your needs are. Using design patterns is more than just write code in a specific manner, in fact it means thinking in a specific manner even before you write a single line of code. Using design patterns as a guideline we help you write code much faster and better, making you therefore more productive…and less frustrated.