No Mediator vs. No Singleton in Cairngorm & PureMVC

I had an errand to run yesterday and my peer at ESRIA, Brian Riley, had some interesting news, so it was a perfect time to call. After we discussed his good news, I then veered the conversation to lack of a formalized Mediator in Cairngorm to get his thoughts. Also known as “Abstract Brian”, he’s a self-proclaimed OOP Purist, always striving for writing the most maintainable, well architected code. He’s also a Cairngorm fan.

My positive feelings towards Cairngorm have waned in the past 2 years. There are a number of reasons for this. The first is that there are finally good alternatives such as MVCS, PureMVC, and Mate. The second is that one of the benefits of Cairngorm, RAD development (allowing multiple developers to work on the same code base) has never really been realized by me. Even in the Flex consulting & contracting world, I’m constantly on my own OR working with 1 other developer and we just communicate our changes to each other thus negating the need for a lot of sequestered abstraction. The third is that the newer frameworks have solved more for the GUI portion of Cairngorm, most notably the Mediator’s in PureMVC. The fourth reason was that, in the early days, if you were with a consulting firm you typically utilized Cairngorm. This was to make sure the client felt comfortable that you were utilizing an industry de-facto standard, and that they weren’t being given a code base that only your firm could maintain. That is no longer the case; as Brian said, Flex is easy. You give any traditional software developer a week with it with some guidance, and they’ll get it. The fifth is that it’s been 4 years… Cairngorm isn’t dead, but when you look at the competition’s resources (PureMVC & Mate’s documentation/examples/etc.), the lack of a formalized Mediator concept, and the still lacking of a solid push methodology, I’m more liable to utilize another framework.

Our original discussion was around 2 things. The first is that Cairngorm has no formalized Mediator. Meaning, there is no one to translate all of the Application Logic to Business Logic. Aka, “a user wants to save a Person Object they created” or “I’ve received confirmation that your Person Object saved, what View wants to know about this success?”. This is just breezed over in Cairngorm and all falls to the developer on where to do this. Most delegate the responsibility of running specific use cases (aka, dispatching events utilizing CairngormEventDispatcher) to the various View’s who handle those use cases. So, in practice, someone would create a login form in LoginFormView.mxml, and when the user clicks the submit button, they’d immediately run CairngormEventDispatcher. getInstance(). dispatchEvent(someCairngormEvent.LOGIN), or something to that effect. The pro’s are that no one else has to handle the details of the logging in process; whatever parent View houses the LoginFormView.mxml will just listen for a success or failure event dispatched from the LoginFormView.mxml. How the LoginFormView.mxml determines success or failure is up to debate. Does he bind to a state Singleton, and react to its data changes? Or, does he utilize the Universal Mind Cairngorm Extensions and wait for a callback? Either one will work. Bottom line, again, all of this logic is self-contained.

As your application grows, this delegation of use case handling and reacting to state becomes nested in a lot of your Views. This can become somewhat unmanageable when trying to debug, so what some people do is try to make one big View that’s smart, and he’ll delegate either data and/or state changes to his children, keeping them dumb and easier to debug. This in turn puts more weight & responsibility on them; aka, more code. Some people don’t have a problem with this. Utilizing code behind (external script source, extending AS using MXML, or AS extending MXML) allows the code to be in “smaller” chunks, and thus more easily manageable. I disagree with this statement, but a lot of people seem to be fine with this. To me, the work of handling events being bubbled up from child views, and determining which children need a state change is the sole responsibility of a Mediator. This is effectively what these parent View’s are doing, except they also have some other View-like responsibilities; making them in charge of 3 things, instead of the normal 2 (event happened so react, or received state change so update children). The point here is that this is a convention built out of need from utilizing Cairngorm vs. a formalized concept dictated by the Cairngorm framework. The closest we have is a good blog post by Farata Systems explaining how to utilize it.

PureMVC formalizes this concept which allows your View’s to focus on just being View’s and exposing methods & public setters for either state changes and/or data receiving. That’s really nice. Unlike code behind, it’s a formalized framework concept to help delegate responsibility of Application Logic to someone who’s sole job is to handle just that; mediation. Cairngorm just assumes you’ll figure it out, you’ll utilize code-behind to manage to code bloat, or you just don’t care because you don’t perceive the code as bloated. That last point is often the case with less design intensive Flex applications because there isn’t a lot going on in the interface beyond mediation. So, Enterprise Developers often don’t see the problem here whereas those from a design background like me get really irritated with the multitude of details a simple View needs to handle.

The second thing we discussed is PureMVC’s lack of a Singleton Model and the pro’s and con’s. The common complaint against Singleton’s is that they are merely global variables in disguise. Say what you will, but the very reason lightweight frameworks like MVCS exist, as well as lightweight languages like JavaScript & Perl prevail is that not everyone is creating these massive, 3 to 5 year life-cycle Enterprise Applications. Global variables are extremely helpful to get things done quickly and/or with really small scoped applications. In business, getting things done quickly is great, and in the case of software, if you’re product has a short life-cycle OR is a prototype/proof of concept, they really shine. One could argue why would you utilize Cairngorm on such a small scope project… which we did debate. It basically comes down to Cairngorm is easy to code generate, you may be comfortable with it, and if you have to change over to a larger scoped, longer term project, you already have Cairngorm in there anyway. The other negative about Singletons is that they make View unit-testing hard because you have to instantiate the Singleton first before you test the View. Um… boo hoo… 1 more line of code in your test case’s build up. Additionally, not every single View in a Cairngorm Flex app will directly bind to ModelLocator; as stated previously, you can have a lot of well encapsulated View’s who merely expose a public setter bindable ValueObject and assume a parent View will set it for them.

While PureMVC does not suffer from the “Singleton Problem”, it’s a real pain in the ass not having direct access to global data. Mediators are squarely on the front-lines of ensuring the View’s they are responsible for have the data they need, when they need it. The con is a lot more code needs to be written to simply get your data; you can’t just reach out and touch it on a Singletons’ public property. The pro’s are the TDD guys no longer get irritated, and PureMVC is already setup for the formalized process of getting your data. Again, it really comes down to the scope of your project, and how much you hate Singletons.

As always, the debates get really really subjective. Once you start talking about a single project, things get a lot clearer. For example, if I were doing a 1 page Flex app (yes, they exist), I wouldn’t use either of the above frameworks… I might not even use MVCS. Others however, cannot live without their framework of choice, and they are actually very productive using it. So… who’s right? No one because you can make a lot of good points in favor of one particular approach. Regardless you CAN get a list of pro/con bullet points and use a weighted approach; aka more dots in the pro side win assuming each dot is weighted the same.

Regardless, I still think Cairngorm needs a formalized Mediator; whether this be a convention, a View, or amalgamation of the UM extensions.

27 Replies to “No Mediator vs. No Singleton in Cairngorm & PureMVC”

  1. Jesse, check out the slide deck from my recent presentation on comparing Flex frameworks (see the menu Conferences under We are going to publish the video of this talk soon.

  2. In regards to global-variables-are-handy-in-small-apps I wonder if Cairngorm is the solution there anyway? As you say, for one page apps you wouldn’t go with Cairngorm because that would be overkill, but wouldn’t that be true in any application small enough that global variables wasn’t an issue?

    It seems to me that there’s no application where Cairngorm and it’s global variables is suitable. For small apps it’s overkill, and for large apps you end up with an entangled, untestable mess because of the globals.

  3. I’m not an OOP Purist, so to me, I don’t mind the Singleton(s) utilized as globals for data. As long as you can bubble up as much of that responsibility to higher level Views, allowing them to deal with handling the global, and having the child Views merely having public setters, you “lessen the damage”.

    I’m sure you’re response at this point is, “ZOMG, don’t use globals crackhead!”. Well, again, they are a lot quicker to use and don’t seem to cause me a lot of maintenance head aches. Like, I had a 3 month project where they + Cairngorm worked good. We had 3 Singleton Models and it worked fine. I did not use unit-testing, had only 2 developers at any one time, and most of the Views were not re-usable; built specifically for what they needed to represent.

    I’ve read your various blog entries on the subject so I know I’m probably not swaying you in the least, I’m merely saying they work for me on some projects.

  4. I can’t resist interjecting my own bias here…

    I agree with Theo that I hardly ever see a point to relying on Singletons. especially in a Framework ( capital ‘F’ ) which is suppose to help you write good code efficiently rather than encourage you to take shortcuts. And as far as I understand it Singletons are _not_ suppose to be global variables.

    But I too agree with Jesse that Mediators are great at solving a problem with most MVC frameworks, that the Views end up being too smart. They have to issue events to the framework ( which means they have to know about the framework ), and they have to know success or failure of an action figure out what to do about it.

    My framework JumpShip ( ) has taken the approach that Singletons should be used as they were intended ( enforce that there is one and only one application wide ). It also uses a Mediator for the View which lets the actually Flex components be agnostic to the framework. And it goes one step further and encourages moving that success / failure logic into the Controller

    I’ve always found it a little strange that the class named ‘Controller’ is usually the dumbest part of an MVC framework.


  5. @Jesse:
    “I still think Cairngorm needs a formalized Mediator”
    Why does it need to be formalized? If you want to write a Mediator for your view, there’s nothing stopping you.

    “The common complaint against Singleton¿s is that they are merely global variables in disguise”
    Singletons are very useful in terms of design patterns and have their place. They are certainly not simply global variables in disguise.
    They represent objects that should only have one instance.
    Many MVC implementations have the model as a singleton simply because you normally only would ever want one store of application data. How you interact with that model (or how your framework iteracts with that model), public vars, getters/setters, events, binding… whatever, is not so important, but in terms of MVC its common sence to have the model as a singleton.

    “if I were doing a 1 page Flex app (yes, they exist), I wouldn’t use either of the above frameworks”
    Why not? That one page app may very well mature into a 100 page app 6 months later.
    Good design at the outset of any project will always benefit in the longer term.

    “It seems to me that there’s no application where Cairngorm and it’s global variables is suitable. For small apps it’s overkill, and for large apps you end up with an entangled, untestable mess because of the globals.”
    I would suggest reading a design patterns book susch as the Gang of four

    Lets remember what Cairngorm is… A lightweight micro-architecture, a collaboration of recognized design patterns.
    In simple terms it makes use of the Front Controller, Command and MVC patterns.

    I find adopting design patterns such as implemented by Cairngorm based apps, its extermely easy to maintain and scale. This said, there is no real reason to use Cairngorm or PureMVC (or any other similar framework). Its really not that hard to implement an MVC based app without any third party framework!

  6. Jethro, the reason I am suggesting it be formalized is that in my consulting, I see others struggle with this concept when it comes to Views and integration with a framework, namely Cairngorm. PureMVC sought to formalize this concept because a lot of Mediator’s that are also View’s in Flash & Flex “do too much”. The Mediator’s job is also pretty simple; listen for events, give View’s their associated data, and route messages from child Views as need be.

    So, yes, there’s nothing stopping me, but there is nothing making it easier for people using Cairngorm either since it’s very nebulous on how you go about it. And no, requiring someone know the Gang of Four’s definition of Mediator, is not acceptable; not everyone using a framework finds this stuff as cool as we do, they just want to be productive.

    I know Singletons are useful, and I know what their usage is. I’m merely reporting the common complaint so that those reading have context for why people advocate PureMVC’s way of data access. And, while you may say it’s “common sense” to have a Model as a Singleton, it’s your opinion; PureMVC doesn’t have it as a Singleton.

    Finally, I disagree that implementing MVC is easy. If it were so easy, we wouldn’t have all of these different implementations with so many different opinions about how to implement MVC. Software in general is hard. Frameworks should make it easy; whether that’s getting up and running quickly such as Gaia, or scaling larger applications such as Cairngorm.

    …hah, and defending Theo here, go read some of his blog entries. He’s actually a very smart, passionate dude. I’m sure he’s already read GoF and has points of contentions with it.

  7. Firstly, I must say that I had no intention of implying Theo was not smart, passionate or a dude!, but the quoted comment was, IMO, ill-informed/inaccurate. No hard feelings Theo.

    Also, I have to say, MVC itself is fairly easy to implement. Funny how its really only AS3 that has soo many “MVC frameworks”. And before anyone starts pointing out non-AS3 MVC based frameworks, yes I know there are some, just AS3 seems to have several already, many of which I feel are un-needed or badly implemented. These frameworks, in differing degree’s do help implement well designed apps in AS3, but they are far from essential if you understand the patterns (and to be fair, if your going to use one of these frameworks, I really think one should understand the patterns anyway).

    Back to mediators, I am not suggesting never to use mediators, but use where appropriate, they are also quite specific, and hence formalizing in a framework makes little sense to me.

    And singletons, why would you not want an object to be a singleton if there should only ever be one instance of it???

  8. ‘And singletons, why would you not want an object to be a singleton if there should only ever be one instance of it???’

    Your right, that’s exactly when you would want a Singleton. The question is whether the Model and state objects qualify under that definition.

    For example what if i want to write a reusable component like a video player and I build it in Cairngorm. Then i decide that I want to build an app with two video players side by side. Since the Model and state are Singletons, there is no way to disentangle these to instances.. They share data and state.

    Press play on one and both play. This exact situation happened to me when I first started using Cairngorm and at that point I realized the drawback of Singletons.

  9. I would argue the design of the applications Model. No reason you still wouldnt have one Model, it just then has sub objects, one per video player. Therefore app data shared between the players is in the Model and the sub models are player specific data.

  10. Jethro misses one of the points of frameworks — to standardize the organization of code so multiple developers can develop the codebase with an understanding of how the interactins work.

    In addition, I’d say that Mate is a great framework which can be used for ANY project, large or small, due it’s lightweight boilerplate.

    As for Singletons in PureMVC, I use them all the time. Not sure what you mean. I don’t use Proxies anymore, they are worthless.

  11. @John, haha, you like frameworks to standardize the code organization, but you don’t agree with PureMVC’s Proxy usage… that’s rad.

    So… how do you do it? Like, do you instead just add data to the Model singleton in a PureMVC Command? Details, details.

  12. @John, Standardizing organization of code is not the sole purpose of the these kind of frameworks, rather to ease the application of design patterns. The design patterns themselves organize code into clear standardized design patterns.

    As for Mate, this doesnt fall into design patterns really. Its a framework to create event driven applications as far as I can tell, not apply common design patterns. This does the opposite of standardize.

  13. I think I understand Jesse’s reasons for wanting a formalized mediator concept. Some of the criticism I’ve received to my criticism of Cairngorm makes the point that for the less experienced it’s good when the framework spells things out explicitly, even if it’s not really necessary. One example is the IModelLocator interface in Cairngorm; it doesn’t require anything from the implementing class, it’s more or less just a name.

    I guess the same would go for formalized mediators, there’s not very much there to formalize. If you look at the PureMVC IMediator interface it’s basically only declares life-cycle methods, things that don’t have anything to do with a class being a mediator, but rather being a participant in the PureMVC environment. It’s not surprising considering that the job of a mediator is so very dependent on the actors it mediates between.

    I think the idea of having formalized concepts in a framework to give those that need it some extra support in making the right architectural decisions is admirable, although I have my doubts whether it does more good than bad. The risk is that you end up with developers who think that for something to be a mediator it has to implement the IMediator interface, even though that interface actually has very little to do with the mediator side of the class.

    Now, I neither work with Cairngorm or junior developers, so I’m not faced with the difficulties of explaining basic software architecture just to get where I need to be in order to be done before the deadline, so perhaps I shouldn’t criticise. As I said, I think the idea is admirable, but from the viewpoint of my ivory tower (where it’s cosy and warm) I don’t think it’s a way to make developers understand software architecture better, but perhaps a way to make them do what they are supposed to and not ask the hard questions.

    Anyway, what I really was going to ask is what kind of mediators you had in mind. There is the mediator concept from PureMVC that you refer specifically to, but there are alternatives. One that I find useful is the Presentation Model pattern, which works really well in Flex.

    Actually, I think that PureMVC does mediators backwards. Since it tries to be platform agnostic it avoids using bindings, which makes you have to do a lot of work that could have been done automatically. (On a platform without bindings there’s nothing wrong with the way PureMVC’s mediators work, but I don’t care because I’m a Flex developer and I want to use Flex to avoid unnecessary work.)

    In PureMVC the mediator knows about the view and is responsibe for updating it. It also responds to events dispatched by the view and translate these into application specific actions (e.g. notifications). The alternative, Presentation Model, does it the other way around: the view knows about the presentation model and binds to its properties. Instead of dispatching events the view calls methods on the presentation model, which then translates these calls into application specific actions. The result is less code that is also much easier to test (which, on the other hand becomes a moot point if you use Cairngorm, but that is another flame-war :) )

    So, I was wondering, which of these two do you prefer? Since Cairngorm doesn’t have the (dubious) goal of being platform agnostic you could do either. I’ve seen examples (although not good ones) of Presentation Model using Cairngorm, and I think it should work fine, but you may have other reasons for prefering Supervising Controller (as Fowler calls PureMVC-style mediators).

    On the other topic of MVC being easy: I’m sure you think that you know exactly what MVC is, everyone does — the problem is that no one can agree on the same definition. There is no such thing as the single MVC concept. Over the decades there’s been quite a few different variations, and what you think of as MVC is probably a mix and match of a few of them.

    Grasping MVC (or MVP, or PAC, or MVP+AC) isn’t hard, you can easily draw a picture with boxes that even a non-programmer could understand. That doesn’t mean that writing an application framework is easy. Writing a simple application framework is, but writing a powerful one definitely isn’t.

  14. Hey folks, got a few questions related to various comments here. I’ve been using PureMVC for over a year, always had great results.
    Why exactly could you not use data-binding in PureMVC?
    Not using proxies?? Why? What do you do when your data-source changes, as is common?
    I like the Mediators of PureMVC because I frequently swap the UIComponents associated with my mediators. Is anyone else making extensive use of this ability?

  15. Theo, good post. I actually agree with a lot of what you said there.
    One point I dont however is…

    “There is no such thing as the single MVC concept. Over the decades there’s been quite a few different variations, and what you think of as MVC is probably a mix and match of a few of them.”

    Sure there are variations on the MVC pattern, but then thats not purely (pardon the pun) speaking, an MVC pattern.

    Model: Application data
    View: Display of data
    Controller: Handle user input, update model state.

    Writing an application based on these concepts is easy. Agreed though, writing a “powerful framework” for novices sure isnt going to be!

  16. @Jethro

    Your definitions of the M, V and C are very high level, hardly more than synonyms for the words. If you want to define something like MVC you have to be a little more specific than that. Not much, but you have to tell me what the responsibilities of the three are, where the arrows point as it were.

    Consider Mate and Ruby on Rails; both are described as MVC frameworks, but the responsibilities of the M, V and C in the two are so different that you would never consider them to adhere to the same basic idea if it weren’t for the MVC label.

    Consider PureMVC, it doesn’t even do MVC, at least not any mainstream variant. “One common misconception about the relationship between the MVC components is that the purpose of the Controller is to separate the View from the Model. While the MVC pattern does decouple the application’s domain layer from its presentation layer, this is achieved through the Observer Pattern, not through the Controller. The Controller’s job is to mediate between the human and the application, not between the View and the Model.” (from Interactive Application Architecture Patterns, a really good history on the subject).

    You may think that it’s just splitting hairs, and I wouldn’t say that the difference between SmallTalk-80 MVC and Taligent MVP is very important, but you can’t say that it’s as simple as the model is the application data. To be able to create good architectures you need to know how to draw the arrows too.

  17. @Theo,

    Personally I wouldn’t describe Mate as an MVC framework at all.
    Not sure how you arrive at that.
    I would describe it as an event driven app framework with dependency injection.

    Back to MVC…
    How the M, V and C communicate IMO is not so important (interfaces, events, observer), what is important is that your application data is clearly separated from the views and that user input is dealt with separately from model and views.
    This way when a user performs some action, the controller handles this action and where necessary updates the model. The view is displaying the model, hence a change to the model updates the views.
    Commonly a view will listen for changes on the model via observer/event as does the controller on user input.
    It comes back to this, once you understand the reasoning to split your code base into models, views and controller, really its just a case of separating the code out. Its simple with flex to dispatch and then listen upon events to handle the communication of the participants.

    Now I am not saying frameworks (macro-architecture, mixture of patterns) are useless, just in terms of MVC alone, not required/needed.
    Working in teams with differing skill-sets, a framework provides a common architecture to work to, and this is where we end up seeing the benefits.
    When hiring you can say “Have you got Cairngorm experience?” and know if the person has they will be able to understand your code-base (at least hope they really do have the experience of course!).
    But when all the team members really do understand MVC and can comfortably read UML, there really is no need for the framework.

    An example of not needing an MVC framework…
    Dont know if you have ever done any Cocoa development on Mac, but this is heavily geared towards MVC development. The actual Cocoa framework to the Mac can be thought of like the mx framework is to Flex/Flash, you create NIB files which form the views, actions and outlets communication. Flex/Flash, MXML views, events communication.
    I have yet to see in use any kind of framework for use in coca development like cairngorm or puremvc for flex! When you develop a cocoa app, you create an MVC application – without an architectural framework like cairngorm/puremvc. Its really not that hard.

  18. From this, among others…

    “Grasping MVC (or MVP, or PAC, or MVP+AC) isn’t hard, you can easily draw a picture with boxes that even a non-programmer could understand. That doesn’t mean that writing an application framework is easy….”

    it seemed you were suggesting its difficult to implement MVC based apps without a framework. Sorry if I misunderstood.

  19. I think you read too much into that. I can see how you came to your conclusion, but it was not what I was getting at.

    A good application framework is something that really helps you build better applications with less effort and in less time. To build such a framework isn’t easy, even if the fundamental idea behind it is simple, like separation of concerns and MVC. Remember that a framework is very different from writing an application. A framework needs to accommodate many different scenarios, be general, not be obtrusive. That is what makes it hard. It’s very different from building applications.

    You can write applications without an application framework just fine, but compared to doing it using a good application framework you will have to do more work, write more code, write more tests and spend more time debugging. If your option is using a bad framework, well, you might be better of without, of course.

    You seem very against the idea of application frameworks, why is that? Are you only trying to make the point that it is possible to live without them, or are you saying that there’s something fundamentally problematic with relying on an application framework? I’m curious.

  20. @Timbot
    ‘Why exactly could you not use data-binding in PureMVC?
    Not using proxies?? Why? What do you do when your data-source changes, as is common?’

    I agree totally. Data binding is a great feature of the Flex Framework but the drawback is that it is a specific implementation for the Flex Framework.

    I find it admirable that PureMVC is not dependent on Flex.

    A lot of Flex developers hold on to Data Binding very tightly but don’t realize that it can be implemented pretty easily outside of the Flex Framework ( And probably with less overhead ).

  21. @Theo My idea of a formalized Mediator is something along those Interface lines, yes. Basically, through an example, someone writes one up that handles events being dispatched from the View, and calling methods/setting properties on the View, usually for state or data changes. It wouldn’t just be a marker interface like IModelLocator in Cairngorm is, but rather much like PureMVC does, an example implementation to illustrate the point that View’s should NOT be doing that stuff. As with any application, this technique works well for mid-size and larger projects, but not so much with smaller ones. Regardless, I still think it’d be helpful for the points you mentioned.

    Regarding type… just something along the lines of either PureMVC with less round-about setup, or a chunk of how the C in MVCS handles it. So far, I haven’t seen a MVP implementation I like. As long as you setup your View’s to have bindings, PureMVC can still utilize “global” data. The higher level View will cascade those changes down to children Views. My issue with the Presenter model (whether Martin’s new or old definition) is that you have multiple View’s with references to this presenter. I like having View’s framework agnostic and communicating their concerns upwards via Events; aka, using AS3 for what it does best.

    Again, the goal here, as you said, is to create a Mediator that others see and go, “That’d be easy to utilize in Cairngorm”. The best definition I can give you is the Farata Systems article I linked to. I’m sure you’d prefer a more formalized definition, but I’m telling you from a Pragmatic point of view, their definition is good enough.

    @Tim, @Jamie: Regarding data binding… I’ve done it in Flash, and it sucks. In Flex, it rocks. I write less code, and get things done more quickly. I’m not sure your implementation, Jamie, because writing getters/setters and model classes that dispatch change events is not my idea of fun when I just use 2 brackets & a Bindable tag in Flex and call it a day.

    Furthermore, for Flex, it’s a lot easier to do exactly what Cairngorm does with ModelLocator in PureMVC; you just have the Commands in PureMVC do the same thing they do in Cairngorm; set data on the Model. The Model in this case a Singleton that you’re views can then bind to. People could argue this relegates your PureMVC Proxies to Business Delegates, which is partially true, but Proxies have persistence so are more powerful and not just “service classes”.

    Regarding admiration of non-Flex dependencies for PureMVC… bleh. I still argue that someone should create a branch of PureMVC where all Notifications inside PureMVC are converted to Events instead, and it’s a branch only used in Flash & Flex projects. If someone did, I’d use it.

  22. @Jesse

    Either I misunderstand you, or you have misunderstood the Presentation Model pattern. As I read your comment, you seem to think that the presentation model is a single entity shared by all views in the application, but this is not the case.

    There should not be only one presentation model in an application, but many. Each view class has it’s companion presentation model class, and each view instance has it’s own presentation model instance.

    Really it’s just like mediators in PureMVC, but the responsibilities are different.

  23. Yes I know, and it works great with the .NET world in a code behind fashion. My issue, however, is that as you know, Flex apps consist of many nested View’s; it’s not always flat. Therefore, if you treat Presenter’s as instances that a View has a reference too, the only way to share code is to share those instances… which gets nasty. If you make it a Singleton, you effectively have the C in MVCS.

  24. Are we talking about the same thing? You mention Martin (Fowler, I assume), which makes me thing we do, but it doesn’t make sense to me. I don’t get why nested views create a problem, and what code behind has to do with this also escapes me.

  25. Having just started a Flex project I decided that I needed a framework. My rationale was that I had good experiences with Spring and Struts and EJB3 on the server side, so the “frameworks are good” idea was in my head.

    Did all the research. Picked pureMVC. Been coding for 3 months. Using it less and less. Starting to dislike it. I have evolved to the position that none of these frameworks actually provide anything to you. I think the MVCS or Model View Presenter patterns are the closest to being correct, but no framework has done any of this correctly. I think they all try and do too much.

  26. Jesse,

    Thanks for being brave enough to suggest that some specific frameworks, ideologies, or theories may not be all they’re cracked up to be in practice. It’s like a form of political correctness for techies where you look around worrying if someone might be offended even it wasn’t meant in such a way.

    Anyway, I’ll toss out a post I wrote on a related topic for anyone who cares:

Comments are closed.