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 ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Gregor Kiddie Sent: Tuesday, October 27, 2009 6:18 AM To: [email protected] Subject: RE: [flexcoders] Binding & Model Objects Having your DTOs physically different from your Domain Objects has a lot of benefit using the assembler pattern to map between the two. You can have entirely different structures for your DTOs, map multiple DOs to DTOs, keep your transport and domain layers separate (also allowing you to use different transport mechanisms AMF or XML over HTTP both easily swapped), and allow you a great deal of flexibility in structuring your application. Downside, yes the conversion process can be expensive, BUT only if you are planning on throwing around massive objects all the time. Taylor your service layer to be more responsive to your needs. Don't write a service which requires the whole object when all you need to send is an id (example, it's the difference between sending a whole email back to the server with the 'read' status marked as true, and just calling a 'markAsRead' service with the id of the email). Use paging techniques to break up your dataset, do you really need to fetch all 10k items now? If you are only showing them in 10 item chunks (i.e. in a datagrid) why not fetch them in 10 item chunks (or a few more for visual performance reasons). Well thought out business services can both reduce the amount of traffic you need to send, and allow DTO mapping to be realistic (on both ends of the wire). 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 Richard Rodseth Sent: 26 October 2009 20:02 To: [email protected] Subject: Re: [flexcoders] Binding & Model Objects Jeff I hope we see some responses to this. I like the idea of non-bindable and immutable DTOs, but isn't it true that if you have a very large list, you've got substantial memory overhead in the conversion of those DTOs to the bindable objects. Or are people tackling that with virtualized collections?
