Flex Data Model Architecture
So, I'm chin-deep in Joe Berkovitz's Architectural Blueprint for Flex Applications... That is to say, this is about the 5th time I've read it. I think it's a great article, as architectural blueprints go... It really helps to make the abstract principles of MVCS more concrete for me.
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!
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!
posted by tom at 12:05 PM
3 Comments:
In some applications it definitely makes sense to hang the model objects off of a single central spot as you describe. The MVCS approach doesn't really prescribe this -- it can make sense to have a single ModelLocator-type place where your unitary model lives. A criterion for this approach might be that the model is compact enough that it makes sense to have the whole thing around at one time in memory, hooked up to a single object. It may even make sense to do this when there is a conceptual "root" of a tree-structured model that can be stored somewhere, and you simply bring in the other pieces as needed.
In ReviewTube this isn't done because there are so many potential "bits of model" that can be fetched from the server -- think of all the keyword queries, user queries that can return sets of Videos. There didn't feel like a logical "root" to the model. So the app focuses instead on allowing views to retrieve these "model pieces" on demand.
The ReviewTube approach is more typical of apps that access a very broad content space, rather than form-driven CRUD apps that are dealing with a model of fairly restricted scope.
This is a great post. I too was confused by how to construct a "proper" flex data model. I had envisioned the rooted tree model but it seemed to heavyweight as well. I will focus on the more nebulous approach.
Derek Basch
ralph lauren poloburberry polo shirtthe north face jacketcolumbia jacketspyder jacketed hardy clothing ed hardy clothesed hardy shirts ed hardy t-shirts ed hardy sunglasses ed hardy mensed hardy womens Wholesale HandbagsCheap HandbagsWomens HandbagsCheap PursesDesigner HandbagsTennis RacquetTennis Racket
cheap tennis racquet
tennis racquet discount
cheap tennis racket
discount Tennis Rackethead junior tennis racketwilson tennis racquet
wilson tennis racket
head tennis racketbabolat tennis racket
Post a Comment
<< Home