C
Clint
So I'm working on a web service that will be going into a relatively
high-volume website. One of the questions I've got right now is in
designing the classes that will be returned by the service.
Let's say that the fundamental class is a store. Got the basic information
about the store (address, name, phone numbers, etc). Now, I also have a
list of the inventory items a store carries, the people associated with the
store (owner, employees, etc), as well as other details. My first thought
was to build a monolithic class called Store, with the other objects stuffed
into collection classes (like InventoryItems, and People).
The problem with that is that when someone hits the GetStoreByID (or even
worse, GetStoreCollection), they'll be getting tons of information that they
may or may not need. So my next thought was to break down the collections
to just a collection of ID's, rather than a full object. Does that make
sense? Because an InventoryItem has a bunch of data associated with it
which would be in the object. This approach seems somewhat more efficient,
but still has some overhead.
The final solution would be just to provide the Store information, with
additional methods to GetInventoryItemsByStoreID, and GetPeopleByStoreID.
Then, if a consumer needs the other information, they'd have to make a
separate call to get it. Each class is streamlined as much as possible, in
terms of data. It does mean more round-trips to the web service (call once
to get the store information, then call another function to get the
inventory items, then another time to get the people. However, it's not
like the second method, which would require an additional call for each item
and each person, which would be ugly, I think.
Actually, there's one other way I've heard of for distributed applications,
but I'm not sure about doing it with a web service. And that's to put some
magic in the "get" property, so that if the sub-object doesn't exist, it
goes off and retrieves it at that time. This means that if the consumer
doesn't need the data, it doesn't bring it back. But to the consumer, it's
not more coding work to get that data.
Anyway, any ideas you architects have, or resources to kick things off would
be appreciated. The problem is that each way "works". The question is more
about what way works best, and what's "more standard". There will be one
primary consumer of the web service, which will be a web site. I could
model everything off the pages it's displaying, and deal with any changes
that come up later, I guess.
TIA,
Clint
high-volume website. One of the questions I've got right now is in
designing the classes that will be returned by the service.
Let's say that the fundamental class is a store. Got the basic information
about the store (address, name, phone numbers, etc). Now, I also have a
list of the inventory items a store carries, the people associated with the
store (owner, employees, etc), as well as other details. My first thought
was to build a monolithic class called Store, with the other objects stuffed
into collection classes (like InventoryItems, and People).
The problem with that is that when someone hits the GetStoreByID (or even
worse, GetStoreCollection), they'll be getting tons of information that they
may or may not need. So my next thought was to break down the collections
to just a collection of ID's, rather than a full object. Does that make
sense? Because an InventoryItem has a bunch of data associated with it
which would be in the object. This approach seems somewhat more efficient,
but still has some overhead.
The final solution would be just to provide the Store information, with
additional methods to GetInventoryItemsByStoreID, and GetPeopleByStoreID.
Then, if a consumer needs the other information, they'd have to make a
separate call to get it. Each class is streamlined as much as possible, in
terms of data. It does mean more round-trips to the web service (call once
to get the store information, then call another function to get the
inventory items, then another time to get the people. However, it's not
like the second method, which would require an additional call for each item
and each person, which would be ugly, I think.
Actually, there's one other way I've heard of for distributed applications,
but I'm not sure about doing it with a web service. And that's to put some
magic in the "get" property, so that if the sub-object doesn't exist, it
goes off and retrieves it at that time. This means that if the consumer
doesn't need the data, it doesn't bring it back. But to the consumer, it's
not more coding work to get that data.
Anyway, any ideas you architects have, or resources to kick things off would
be appreciated. The problem is that each way "works". The question is more
about what way works best, and what's "more standard". There will be one
primary consumer of the web service, which will be a web site. I could
model everything off the pages it's displaying, and deal with any changes
that come up later, I guess.
TIA,
Clint