Flex Data Model Architecture
I think I'm a little slow on the uptake when it comes to architecture. Old habits die hard, and years of working on small, underfunded projects have molded my thought patterns accordingly - I always seek the most direct approach that works. Even though this is not my first exposure to MVCS by a long shot, I still find myself getting a bit lost in the translation between the idea of MVCS and the details of how you implement it in a real world project.
The code examples that are shown in Joe's article are only moderately helpful to me - it wasn't until I opened the source code itself and could see the import statements that some of it became clear.
For example, the Model portion of the app. After reading the article several times (and also referencing Aral Balkan's article "Defining Data Models"), I was still unsure of the appropriate place to instantiate the model classes, and I also thought that there should be a single Model class that encapsulated the other model classes. I was visualizing the model as a single respository for all the data needed by the application, which would have bindable properties (sort of like a model defined by mxml Model tags). After reviewing the source code, I see that the model is really implemented as a set of Value objects that are instantiated in both the Controller and the Services, and are passed around the application.
I'm not used to thinking in this way. When someone says "this architecture is made up of 4 parts" I am thinking of 4 discreet parts. When someone refers to "the Model" I naively think "there's a single model object somewhere". So I'm trying to adjust my brain to the concept of a nebulous model that consists of several Value Objects being tossed around the app.
But I'm also (maybe naively) wondering if it wouldn't be better to have a single Model that encapsulates all the data. That would have a couple main benefits, in my estimation:
1) It would be easier to serialize the model and save it in a local shared object for later restoration (the purpose of the model is to handle state, correct?)
2) It would be easier to store revisions of the model for undo/redo purposes
3) It would be easier for the view to bind to it
This is what the mx:Model tag has going for it, but the problem there is you can't have strongly typed data.
I'm pretty sure there are architectures that work this way - it sounds kind of like what Aral describes in the "Using Class-Based Models" section of his article. But maybe I'm reading Joe Berkovitz's code wrong... Pretty sure I'm missing quite a lot here - hopefully I haven't said anything that is obscenely stupid.
Hopefully some of my readers can help me fill in the blanks!