By paddloPayday loans

Home > ActionScript, Design Patterns, Flex, MVC, OOP > Is MVC Obsolete? Flex, ActionScript 3.0 and the MVC Design Pattern

Is MVC Obsolete? Flex, ActionScript 3.0 and the MVC Design Pattern

Another View of the MVC Design Patterns

A while back Brian Lesser, another O’Reilly author and top notch Flash Media Server developer, mentioned that he did not especially care for the Model View Controller (MVC) design pattern. While he cited some references, I never paid much attention to it at the time, especially since Chandima kept writing these brilliant pieces on Pure MVC. Further, I had promised myself that I wouldn’t touch MVC until I had worked my way through all of the design patterns using ActionScript 3.0 and felt comfortable with Flex. So I really am no expert of MVC and have relied on Chandima for that particular compound design.

After weeks of pounding my head on the Prototype pattern, I was thinking of taking a break and sending a torpedo into the Singleton to let off some steam. However, before sticking my neck out (yet again) I thought I’d ask Brian why he didn’t particularly care for the MVC, resulting in a very thoughtful article. (See http://broadcast.oreilly.com/2008/10/mvc-as-anti-pattern.html) Brian asked for Chandima’s and my reaction. Not having spent that much time on the MVC, my reaction was based on the logic of the article which to me made perfect sense. However, this is a case of “What do I know?” The annual OOPSLA conference is coming up this next week and I will be bringing up Brian’s points to big brains that attend OOPSLA–and I hope some more Flex/ActionScript/Flash developers will be there this year! So maybe after next week I’ll have some comments from seriously bright programmers in addition to our seriously bright programmer, Chandima.

So take a look at http://broadcast.oreilly.com/2008/10/mvc-as-anti-pattern.html and we’d like to get any copies of your comments, thoughts, and wisdom that have you about Brian’s article to post here as well.

Share
  1. October 12, 2008 at 5:02 pm | #1

    Hey Bill,

    Although popular component frameworks such as Flex and Swing provide some controller functionality, there still is a need for an abstract notion of MVC in your application. Granted, some applications are simple enough where it isn’t practical to invest in the time to implement MVC. However, as your application matures, and you’re required to add new features to your software, the benefits you naturally gain with MVC (maintainability, extensibility, scalability, and testability) really payoff.

    I’ve been down the “don’t use MVC” road numerous times with Flex, and 9 times out of 10, I’ve been burned later during the application’s life-cycle. Now, should you use Cairngorm, PureMVC, Mate, or your own as a MVC framework for your application? Well, that’s an entirely different discussion.

    Dan

  2. October 12, 2008 at 6:21 pm | #2

    Hi Dan,

    Thanks for your comments. Keep in mind that I’m not a “No MVC” guy — I’m the “I don’t know MVC” guy. Having said that, the key point in Brian’s article seems to be, if you have built-in controllers, you have an MV situation and not an MVC situation. Conceptually, though, you do have a point — the controllers, even if they are built-in– are there as an abstract notion if you have an MV model with the built-in ‘C’. Further, Brian points out, if you don’t need to submit any forms, what do you need MVC for?

    Anyway, my purpose in providing a link to Brian’s article is to generate some discussion of the points Brian raises. Those points, plus the ones in the referenced articles, are intriguing ones and by no means easily dismissed. As I noted in the article, next week at the OOPSLA conference, I’m going to broach Brian’s points and will be adding feedback to this blog based on what I find out. (Two years ago at the same conference, some very bright people slam-dunked the Singleton, and I hope to follow up with some important questions about that design patterns as well.)

    My hope is that we can generate light here and not heat. Design patterns are important OOP constructs for all of us, and the more views and insights we have, the better served we all are. Thanks again for your comments, and I am hoping to get further ones in reaction to Brian’s article. (You also might want to add a comment to Brian’s blog.)

    Kindest regards,
    Bill

  3. October 13, 2008 at 2:58 am | #3

    I would like to add, that having a rich client with most of the business logic in it might be a potential security risk, since client applications can usually be decompiled quite easily and a rich client with business logic might unveil more information, then an application structure, where the business logic runs on the server.

  4. October 13, 2008 at 6:53 am | #4

    Hi Dan,
    I think it is important to distinguish between MVC and application frameworks in general. From what I’ve seen, Mate is not an MVC based framework. If Mate makes possible building large maintainable applications then you don’t really need MVC.

    I also think it is unfortunate that MVC has come to mean so many different things in different contexts. It’s almost as though it has become synonymous with any system that uses separate objects to render data structures and other objects to manage events. But, there are many ways to do that ranging from the Observer pattern, to Flex’s controls and data providers, to treating containers as a state hierarchy where events that can’t be handled at one level bubble up to the next container, to creating an events bus.

    I do understand that forcing a team to register events with one global front controller enforces a certain type of team discipline. But I think there are better and more modular ways to handle events and that the focus on MVC can get in the way of exploring more effective architectures.

    I have built a large application with only the Flex framework that a team of seven people have maintained without running into problems. It did require that the team buy into a specific architecture, but it did not require MVC.

    Yours truly,
    -Brian

  5. November 4, 2008 at 3:06 pm | #5

    I broached a number of the points that Brian made at the 2008 OOPSLA meetings in Nashville last month, and the general reaction was that Brian’s points seemed reasonable to everyone I talked with. However, no one said that the MVC architecture was dead or even sick.

    Brian’s comments above seemed to sum up a lot of the general feeling among OOPSLA members I talked with. They are operating on a level that includes a lot of solutions beyond the MVC architecture but nonetheless see MVC as viable solution to several kinds of projects. In thinking about projects and design patterns and pattern architecture, the sense I got was you start with the problem at hand, first and foremost. What’s the goal? The more solutions you have in your programming utility belt, the more likely you’re able to pull out the right design pattern and/or architecture and achieve the goal.

    Like everyone else, once having mastered a pattern or architecture, it’s comfortable and you know what to do with it. For me, I spent a lot of time with the State pattern and I probably overused it. It’s easy to do and fits into human nature. However, where you have a changing technology and set of projects to handle as we all do, staying in your comfort zone is a dangerous choice. Likewise, a single approach is like trying to build a house using only a hammer. It’ll get a lot done, but when you need a saw, the hammer just won’t do and can wreck havoc if you try to use it as a saw.

    PureMVC is an attempt to improve the MVC–not to keep it the same. As such it is part of the evolving architecture that may or may not best achieve a given goal. If it doesn’t, it’s time to add more patterns and architecture to your utility belt. (Joe the programmer?)

    We just keep on truckin’ (evolving) and sitting still ends that evolution.

    Bill

  6. November 11, 2008 at 4:13 pm | #6

    So…how did the big brains take it? Any more discussion to be had on this subject?

    By the way, I’m firmly in the “I don’t know MVC” camp myself…

  7. November 13, 2008 at 5:45 am | #7

    Hi Rich,

    The guys I talked with are not quite as rigid as some of us are. They’re always looking for better ways of doing things, and they’ve been around long enough to know that things change. Most were around before Design Patterns, some even before OOP. So for them, change is part of the nature of programming. By the same token, they don’t throw something out simply because it’s out of style.

    For me, MVC has several logical and useful benefits, and the Pure MVC does as well. However, as Brian points out, some things done with the MVC may be more ritual than utility, and I’m glad he’s spoken up. It makes us stop and think, which is always a good thing.

    Bill

  8. Jeff
    November 14, 2008 at 11:52 pm | #8

    I may be chiming in a little late here, however, the MVC topic is one that I have struggled with for quite some time.

    I come from a totally different corner of the programming world – zero Java, C++, etc. Coming from the ‘Flash AS2 RIA’ world, I resisted the verbose and strict nature of AS3. But when I began using Flex2 & 3 and saw how incredible coding became with ‘real’ code hinting, robust debugging, and smart compiler (among many things, let’s me know that I need to import a class – thank you Ctrl+space), I became very excited about embracing coding frameworks and practices that earlier just seemed silly.

    So I began studying frameworks. I saw the merits of the MVC model immediately. But most of my projects were MV. I would ask myself, “Should I try harder at finding a way to make my code fit the ‘C’ part of MVC”? The reality was that my data was on a server and therefore my ‘C’ was an ‘S’. Most of my controller work was being performed in my Service class.

    How relieved I was to read Brian’s article. Being new to the whole OOP MVC world, I thought I was doing something wrong. Like waking up from a hard sleep, it just took me a little while to realize that Flex’s Event architecture and Databinding were handling much of the heavy lifting for me. Had I come from a Java background, it might have been clearer that a hand-coded Observer pattern wasn’t necessary in Flex.

    **This is to any potential AS3 OOP/Framework authors out there. I have read 6 books on OOP/design patterns/frameworks and the book for Flex developers that hits the target on those topics hasn’t been writen yet! Many have made attempts, but that book just hasn’t been written yet. Just sayin’. As soon as someone can bring it all together from a Flex/AS3-centric viewpoint, I’ll be the first one in line.

  9. October 17, 2009 at 1:37 pm | #9

    The issue is that people get stuck on what they are accustomed to. MVC is great for applications that benefit from it, and terrible for applications that don’t benefit from it. No one should ever use a particular Design Pattern or Framework or Micro-Framework just because they like it. Every new project needs its own unique evaluation as to what Design Patterns will be of short term and long term benefit. If you think MVC is perfect for everything, hopefully it is because you’ve only developed applications that benefit from it. If you think MVC is worthless, it is because you haven’t done any applications yet that benefit from it. I’ve worked on many that do and many that don’t, all within the realm of ActionScript. And regardless of what patterns you use, and even when there are none that fit what you are doing, it is always important to follow the core rules of OOD. Sometimes people get so hung up on the patterns that they forget to follow the rules that they are based upon, which are universal.

  10. October 18, 2009 at 2:54 am | #10

    Hi Phillip,

    You’ve summarized a good deal of what we’ve been saying. Design Patterns are tools, and depending on the problem you’ve got in front of you, some are more applicable than others. The MVC is a special case for two reasons. First, it is not a design pattern, but it was introduced to show how classes can be loosely tied and interact. Second, the MVC has been widely used and misused, and its association with design patterns is so skewed, that it’s hard to find the way back to its original purpose—an illustration.

    When in doubt, head for the OOD principles, and you’ll be in good shape. After all, remember that design patterns were originally offered to help maintain OOD and not as a solution in and of themselves.

    Kindest regards,
    Bill

  11. Alex
    November 12, 2009 at 12:07 am | #11

    A Simple description about what part of Flex goes to what part of MVC.

    • Chandima Cumaranatunge
      November 12, 2009 at 6:31 am | #12

      Alex, I’m working on an MVP post that will answer this question.

  12. November 12, 2009 at 4:12 am | #13

    Hi Alex,

    I’m not quite sure what your comment is about. It sounds interesting, though. Would you mind commenting further?

    Thanks,
    Bill

  13. November 12, 2009 at 9:05 am | #14

    The subscription email notifying me about Alex’s post included an anchor tag that was not included here because the comments don’t support anchor tags. He was linking to his opinion on the matter on another site: http://askmeflash.com/qdetail/309/how-to-understand-and-use-mvc-framework-in-flex-any-example

    I’m not supporting or opposing the opinion, just putting the link here for him, not in an anchor tag, so it shows up.

  14. November 13, 2009 at 2:39 am | #15

    Hi Philip,

    Thanks for that clarification. I guess Alex was just sending us a link to a QA site. It’s a breakdown of how Flex is ordered in MVC. I’d be curious whether that breakdown is a reflection of how Flex (or Flex Builder) was actually constructed or whether it’s just a description of Flex in MVC elements. It’s hard to tell from short descriptions without a larger context.

    Kindest regards,
    Bill

  1. No trackbacks yet.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>