This is consistent with the way I've done things. In my case conversion was necessitated by needing a "dirty" flag on each record, but I also like it philosophically.
However, in another portion of the application that I don't own, there is a large DTO displayed in a table (with user-configurable columns), and I don't think we can pay the price of conversion without also implementing pagination/lazy loading. On Tue, Oct 27, 2009 at 7:15 AM, Gregor Kiddie <[email protected]> wrote: > > > 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 > > 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 > > > >
