Extending the Presentation Model pattern for a better architecture
Problem
When applying the Presentation Model pattern to a fairly large application where you want to reuse the parts of the application backed by a presentation model class you end up with a problem where the UI state is the same and this might not be what you want. Therefor you need to extend the presentation model pattern to make sure you only reuse the same data, not the UI state.
Solution
The solution to the problem is to introduce a model class which stores the data retrieved from an external source and compose the presentation model with this class to enable reuse of large components without having the same UI state.
Detailed explanation
When it comes to patterns there is one I always tend to use when writing Flex applications and that is the Presentation Model pattern. Using this pattern I am actually able to unit test most of my UI logic without having to write fragile tests which involve testing the actual UI components
.
However there is one flaw with this pattern when
it's being used on large applications where you might have a
scenario where you want to reuse large parts of an application
which has one presentation model. When reusing such a component you
end up having the same
state information as well as the same
domain object data. This is obviously not what you want
when reusing a UI component and therefor you need to change your
presenation model.
Børre Wessel mentions this approach in
his
Flex in the enterprise talk and his proposed
solution of having a separate set of models handling the
communication with the server and storing the retrieved data is
great. We use this approach on my current project and it has made
our architecture better and more robust for changes in the UI. It
also makes the Presentation Model classes easier to understand as
they end up having just one responsibility: handling the state of
UI components.
In my current application the Server Model classes
get composed with classes extending Remote Object which makes the
class responsible for retrieval and storage of server data. The
Server Model classes end up looking a lot like
Data Access Objects, in the sense that they
have methods for retrieval of data and handle all communication
with the data source.
This recipe was originally posted on the Small man, big mouth blog.
+
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License. Permissions beyond the scope of this license, pertaining to the examples of code included within this work are available at Adobe.
