What’s included in the re-factored version?

• the MVC approach in now demonstrated not only for the module, but also for the item renderer used in the list component
• the model adapter pattern is demonstrated too
• some other minor refinements

Adapting the Model into a Presentation Model

Let’s see the Model Adapter pattern in more detail:

The MXML usage of the model adapter is pretty straight-forward – you can see this in the StatisticsView.mxml:

<programmerListItemModel:ProgrammerListItemModelAdapter id="modelAdapter"
    source="{model.programmers}"/>

And then instead of using the model.programmers you can use modelAdapter.resultCollection:

<list:CustomLayoutList id="list" styleName="programmersList" width="550"
    layout="{model.inAdvancedView ? verticalLayout : fluidLayout}"
    dataProvider="{modelAdapter.resultCollection}"
    itemRenderer="{new ClassFactory(ProgrammerListItem)}"/>

This adaptation is actually in a way demonstration of what means to have a pure abstract model and a presentation model (like in the MVP pattern).

This talk is based on a series of articles I wrote last year:
Introduction to Flex Application’s Architecture – Part 1 – Cairngorm
Introduction to Flex Application’s Architecture – Part 2 – PureMVC
Introduction to Flex Application’s Architecture – Part 3 – The Gugga Approach

Since we’re gonna compare a couple of architectures and some architectural approaches, it is important to establish a common ground in understanding why we need an architecture and what problems an architecture tries to solve.

Why architecture is important?

Architectures are important in situations where we need to:

• scale things up in both size and complexity
• prepare and follow a plan

The important thing to remember is that architectures are rarely obvious. And in most of the cases they emerge from the practice.

MVC vs. MVP

I’ve included some differences between MVC and MVP as I perceive them, but in the discussion with we ended up with the conclusion that “MVP is speculatively different from MVC”.

Architectural Frameworks

We’ve discussed the most popular architectural frameworks – Cairngorm and PureMVC, outlined their flaws and benefits, but mostly flaws. I’ve tried to persuade the audience in the need of a more granular approach, that can be applied not just on MACRO-application level, but also on a module level and even on component level of granularity.

It is important to note that the proposed ideas are not a complete architectural framework, but rather an approach. And since this is just an approach, there are no rigid rules – the developer must take his decisions without relying on strong and proven rules. The difficulty comes when you have to decide on what level of granularity you need to set up an MVC-infrastructure. Whether to have a single view and single controller and whether to have multiple views and many controllers?

Detailed sample is published in the next topic – MVCS Example.

Great Comparison Between Frameworks

The following is a great comparison between Flex architectural frameworks:

• Part 1 – Introduction
• Part 2 – Get Control with Cairngorm
• Part 3 – Framework Agnostic Views with PureMVC
• Part 4 – IoC with Swiz
• Part 5 – Mate, the Pure MXML Framework
• Part 6 – The Exciting Conclusion

This series of articles build the very same application but with different architectural approaches. The Source Code is available at GitHub.