The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Tiered Application Data Retrieval

Given a client that requires multiple sets of related data, what is the better way of allowing it to request data? Require it to request each set separately or implement a "command" based system where a single command will return multiple sets?

For instance, the client wants to show a dialog that allows the end user to edit a Contact record. Each Contact has multiple phone numbers and multiple email addresses. So, the client needs:

1) The Contact record.
2) The ContactPhoneNumber records.
3) The ContactEmailAddress records.

The choices for creating the server API are:

A) A single command called Contact.Edit that returns all three sets.


B) Three Commands that allow the client to get what it wants. NOTE that a command does not equal a trip to the server since multiple commands can be sent to the server at once. So, the three commands here would be: Contact.GetById(), ContactPhoneNumber.GetAllInContact(), ContactEmailAddress.GetAllInContact()...

Obviously, option B is more flexible. Is there any reason not to go with that?
Backwoods Dev Send private email
Friday, September 14, 2007
I'm not sure what Contact.Edit would return, but in my object modelling preferences, for option B, you would have Contact.PhoneNumbers and Contact.EMailAddresses collections.  Now, whether they were populated in one trip to the database when you did Contact.GetById or lazy-loaded on demand, that's another matter.
Cade Roux Send private email
Saturday, September 15, 2007
I guess your commands are part of some "business" or "middle" tier, and not placed inside the client.

If this is the case, go for A by implementing it on top of B....

Hide the commands of B by keeping them "private", "internal", or "protected"... or whatever your language supports

So you will combine a simple client preserving some flexibility for the future

Johncharles Send private email
Monday, September 17, 2007

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz