Jeff,
Yeah, I just jumped all over the DTO part of the discussion. Our DOs
never get near AMF.
We convert everything btw... each record in the DG ends up as an
instance of a DO (which is why the performance of the service layer is
so important).
With DOs, we do make them bindable, but we use custom events to fire the
bindings, and we never ever make the entire object bindable, only the
fields required for the UI. The cheat here is when assembling the DO
from a DTO, use a method that doesn't go through the setters, and then
dispatch the change event once done, that way the binding operations can
be done in a single frame rather than being spread out.
Example (not the best architecture though).
public class fooDO extends EventDispatcher {
private var _bar : String;
public function set bar( b : String ) : void {
if ( _bar != b ) {
_bar = b;
dispatchEvent( "fooChanged" );
}
}
[Bindable("fooChanged")]
public function get bar() : String {
return _bar;
}
public function assemble( dto : FooDTO ) : void {
_bar = dto.bar;
dispatchEvent( "fooChanged" );
}
}
Quickly written out, but if all the bindable properties are fired off
"fooChanged" then the non-bindable DTO can be assembled into a Bindable
DO and cut down on the number of change events being fired. If the
default "changeEvent" is used, events will fire on each setter used
which is where the presentation is going.
Is that explained badly? Non-bindable DTOs assemble to bindable DOs in a
way that minimizes the amount of event slinging going on...
Gk,
Gregor Kiddie
Senior Developer
INPS
Tel: 01382 564343
Registered address: The Bread Factory, 1a Broughton Street, London SW8
3QJ
Registered Number: 1788577
Registered in the UK
Visit our Internet Web site at www.inps.co.uk
<blocked::http://www.inps.co.uk/>
The information in this internet email is confidential and is intended
solely for the addressee. Access, copying or re-use of information in it
by anyone else is not authorised. Any views or opinions presented are
solely those of the author and do not necessarily represent those of
INPS or any of its affiliates. If you are not the intended recipient
please contact [email protected]
________________________________
From: [email protected] [mailto:[email protected]] On
Behalf Of Battershall, Jeff
Sent: 27 October 2009 13:43
To: '[email protected]'
Subject: RE: [flexcoders] Binding & Model Objects
Gregor,
I'm doing a good bit of what you describe already - like chunking the
number of objects transferred, only transferring what is needed, etc.
My big question based on Sean's preso was making domain objects
bindable. Right now, I am, for the most part. For example, when
editing a specific record in a datagrid, it makes it so much easier to
have that object bindable so I can load it into a form and have the UI
reflect that object instance. To NOT make domain model objects bindable
would mean creating a third layer for binding and loading a non-bindable
model object into it. That is a total headache, but I'd do it, if it
really made that much difference. I'm a little skeptical that a
bindable AMF model object is going to fire off a bunch of events when
received by the Flex client.
Jeff
