Logic in Mediators

Pratik's Avatar


04 Dec, 2013 12:55 PM

i have a particular situation where i have joined a organization and i have been assigned to review the current project developed in RL and point out any wrong use of architecture spotted which may be harmful for the further development of project and also i need to convert/develop the same project for android. I have seen many discussions which say that all logic related to the views should be handled in views and mediator is just a relay but i need to know the specific advantages/ disadvantages to this fact so I can create a proper report for the Team.
Here are some of the facts i noticed in the project which i consider to be incorrect :-
1. Mediators ranging from 3000 - 5000 lines .
2. View logic handled in Mediators like view members accessed from mediators several hundred times.
3.Models Injected into views and all the data manipulation of models happening in mediators.My colleague provided a argument for doing this that the socket is read so much often that handling so many events fired from models will make the app. slow hence the direct access.

Please if i can get specific arguments as to why this should not be done especially the mediator handling logic view part. , i can prepare a proper report

  1. 1 Posted by Pratik on 05 Dec, 2013 05:02 AM

    Pratik's Avatar

    is any one there???

  2. Support Staff 2 Posted by Ondina D.F. on 05 Dec, 2013 11:10 AM

    Ondina D.F.'s Avatar

    Hello Pratik,

    is any one there???

    I'm here now:) But, you have to know, we (staff members) can't be present on the forum all the time(24/7), because ... well, first of all, we need to sleep as any other humans ;) We also work for a living , have families..e.t.c. We do our best to respond as soon as possible, though.

    I'm not going to get into all the details and repeat all that's been already said, because it would take me too long. Hopefully, others will chime in and add their own opinions on the topic.

    If you've been reading through the discussions on this forum about Mediators, as you said, then you've noticed that the main keywords are:

    a - reusability
    b - portability
    c - loose coupling
    d - single responsibility principle (SPR) , separation of concerns

    Following those principle while designing your Views/Mediators allows you to:

    • reuse same views in different application ( for example a LoginView)

    • use the same logic for other platforms / languages

    • use the same view with other frameworks or other design patterns

    • build modular applications

    • improve the readability of the code, its maintainability and to write testable code

    A Mediator should not keep state of its View. It is not meant to act as "code-behind"
    Its role is to "mediate" - to act between parties ( between the View as a user interface and the rest of the application). If the Mediator is doing more than that, that's a sign that you either need another pattern (Presenter, for example) or you don't know enough about Mediator's responsibilities at the moment.

    Having 3000 - 5000 lines of code in any class, not only in a Mediator is bad, in my opinion. 5000 LOC in a Mediator could also be a sign that the mediated View is too large and it's time to split it into several Views, each of them with a designated role and its own Mediator. It might be very important especially when building a mobile app!!

    It is easier to reuse a Mediator in a mobile application, if it is only listening for custom events or Signals dispatched by the View . Whether it is a Mouse click event or a Touch event , the Mediator should not care, it only reacts to a custom event or a Signal emitted in the handler of Mouse or Touch event.

    Here, just a summary of all that's been already discussed on this forum and been said in books, Best-practices articles, about MVCS-Actors' roles:

    I highly recommend to read some of, or all, the articles/books listed bellow, before making a presentation.

    Recommended readings:


    [1] Gang of Four - Design Patterns: Elements of Reusable Object-Oriented Software: - http://c2.com/cgi/wiki?MediatorPattern

    [2] Clean Code: A Handbook of Agile Software Craftsmanship: - http://www.amazon.de/Clean-Code-Handbook-Software-Craftsmanship/dp/...

    [3] Code Complete: A Practical Handbook of Software Construction: - http://www.amazon.com/dp/0735619670/?tag=stackoverfl08-20


    [4] http://joelhooks.com/2011/03/12/an-introduction-to-robotlegs-as3-pa...

    [5] Robotlegs Best-Practices: - https://github.com/robotlegs/robotlegs-framework/wiki/Best-Practice...

    [6] ActionScript Developer’s Guide to Robotlegs: - http://shop.oreilly.com/product/0636920021216.do

    [7] ActionScript Developer's Guide to PureMVC: - http://shop.oreilly.com/product/0636920022459.do

    [8] ActionScript 3.0 Design Patterns - http://www.oreilly.de/catalog/9780596528461/ - http://www.as3dp.com/

    [9] Adobe Cairngorm 3 - Guidelines: - http://sourceforge.net/adobe/cairngorm/wiki/CairngormGuidelines/

    LOC (lines of code)

    [10] Cyclomatic complexity: http://en.wikipedia.org/wiki/Cyclomatic_complexity

    [11] http://stackoverflow.com/questions/20981/how-many-lines-of-code-is-...

    [12] http://programmers.stackexchange.com/questions/185925/how-important...

    [13] http://programmers.stackexchange.com/questions/155488/ive-inherited...



  3. 3 Posted by Pratik on 05 Dec, 2013 12:33 PM

    Pratik's Avatar

    I didnt mean to offend you guys.Of course you have other responsibilities ,Its just i was not sure of time zone and wanted to only confirm whether i reached you guys .
    I will go through the Presenter Model and see if it suits my requirements.
    Thank -you for support. :)

  4. Support Staff 4 Posted by Ondina D.F. on 05 Dec, 2013 12:42 PM

    Ondina D.F.'s Avatar

    No offense taken :)
    Good luck with your presentation!

  5. Pratik closed this discussion on 06 Dec, 2013 09:21 AM.

  6. creynders re-opened this discussion on 06 Dec, 2013 10:15 AM

  7. Support Staff 5 Posted by creynders on 06 Dec, 2013 10:15 AM

    creynders's Avatar

    Sorry Pratik,

    I didn't have time to react earlier. Ondina's quite right. Mediators aren't meant as code-behind, although many people seem to interpret them that way.

    The main idea of mediators is to provide easy reuse of views (through decoupling). The views should be totally system (i.e. application) agnostic AND framework (i.e. Robotlegs) agnostic. That's the only way to ensure you can take a view from one project and paste into another w/o too much hassle. Mediators on the other hand are the "glue" between the views and the rest of the system. I.e they concretisize the semi-abstract views. This means that mediators have a lot of system-knowledge; they access models, concrete system events, maybe even services (more on this later)
    However, if a view can't exist w/o its mediator (since it contains view logic) it becomes problematic to reuse the view. You can't just take the view out of the project and paste it into another once, since it needs the mediator too. But. If you paste the mediator along with the view you'll be adding a lot of the application-specific knowledge to your new project, which means you'll be hunting down those application-specific references inside the mediator. Good luck with that in a mediator of 5000 LOC. (5000? Seriously? Wow.... Again, more on that later on)

    There's one correction to Ondina's (no offense!) explanation I'd like to make: even when using the Presenter pattern you'll need mediators. Maybe even more so, since the presentation model needs to be assembled somewhere, you could do this in commands, but in effect you'll be actually creating short-lived mediating fragments. It's far easier to do this in a mediator (when using the Presenter pattern !! Not in "normal", recommended RL usage)

    Then, should mediators access models, services, etc? Yes and no.
    I know, that's not really helpful. But this is a situation in which you need to have some experience to know when to stick to best practice (=no direct access to models and services in mediators) and when to break it. In general, as a rule of thumb, try to avoid it as much as possible. Views (and in extension mediators) shouldn't be aware of the source of data, nor even whether the data is already there or is loaded/generated on the fly.
    It's a bit hard to explain, but you'll notice that if you keep that rule of thumb in mind, you'll be creating far more versatile and reusable views and mediators.
    For example: you have a mediator which calls a service directly and uses its output in the view. Then later on, requirements change, and you realize you need that same data someplace else. That's where trouble starts to kick in. Maybe the data needs to be loaded before the view is added to the stage (i.e. the mediator doesn't exist yet) or the data needs some massaging before its put in the model and can be consumed by the view. These requirements will force you to start hacking around or to rewrite your mediator entirely.

    Last, but definitely not least. 5000 LOC in a file is just ... gruesome. It's the #1 rule: keep your classes short and sweet and let them have 1 responsibility (SRP) Only one. You'll be avoiding a world of pain. A world of pain, I say ;)

    My long 2 cents.

  8. 6 Posted by Pratik on 06 Dec, 2013 10:39 AM

    Pratik's Avatar

    Hi Creynders,
    No need to apologize,you guys are doing a fantastic job.Yeah, these mediators here are a mess...i have been banging around my head so hard but still am not able to get a clear idea of the workings since the Models are accessed from practically everywhere in a Mediator.There is no single Point of Access or a Pattern to the Work Flow.The Commands are completely bypassed and all the model /service data manipulation is done in mediators. To make My Life a living hell the guys earlier have used Global variables everywhere(Classes with static variables). Now am assigned to clean up this mess.
    Thank-you for the insight.
    Again appreciate the swift and useful support you guys provide.

  9. Support Staff 7 Posted by Ondina D.F. on 06 Dec, 2013 10:48 AM

    Ondina D.F.'s Avatar

    There's one correction to Ondina's (no offense!) explanation I'd like to make: even when using the Presenter pattern you'll need mediators.

    Yeah, sorry for not being clear. What I had in mind was Presentation Model used like in Joel's demo:

  10. Ondina D.F. closed this discussion on 23 Dec, 2013 09:22 AM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac