Hello again.

I use a pretty classic UI design wherein users view a list of records (an EntityCollection) from a pick-list and select one (or more) of the records for editing.

Using adapter, it's a balancing act: when I generate the pick-list, should I prefetch all the related entities and collections and send the fully loaded EntityCollection across the wire, or should I create an EntityCollection with "skinny" entities (without all the related elements) and then make additional calls to the server when the user selects the record(s) that he wants to edit?

Advantanges of fully-loaded: one call. Subsequent entity editting calls are pulled from the EntityCollection without having to make new calls. Downside: EntityCollections often have main entities each with several related collections themselves. This Collection can be quite large, I think (even if I limit the number of records in the collection)

Advantages of "skinny" collection: Small collection crosses the wire. Downside: multiple server calls.

My applications must all be designed to run over the internet using remoting or web services (usually remoting).

What do you guys do?

I would like the server to report back to me what the size of the EntityCollections and Entities are that it received and transmits. How does one go about doing that?

Thanks all.

Jeff

It really depends on the size of the data send when the full set of entities is fetched. If it is significant, it keeps the server occupied for an X number of seconds. Having multiple calls to the server is also bad in case of a lot of clients or potential growth of teh number of clients: the more connections made by the clients, the less scalable your solution is.

However, if the number of calls made is low, as in: 100 root entities send and only 2 or 3 result in the fetch of additional entities, it's well worth it to use the 'call later' route. Though if the # of additional fetches is high, it will become a significan burden for the server, and you then have to decide to prefetch it all.