A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
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?
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.
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
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz