Hi all,
This time I want you opinion on the following scenario:
I have a service which returns info about an entity. Some of the information is based on lookup values (lookup=code/decode, such as "male/female", "small/medium/large" etc.)
My options to output these values from the service are:
1. output them as the coded integers (male=1, female=2) - this is a problem because I shouldn't expose my inner data to the outside world, not mentioning that the outside world has no idea what "1" and "2" means !
2. output them as strings ("male","female") - this also pose a problem since I'll need to create an enum for every lookup field - if my DB has about 30 different lookups (genders, sizes, countries, states....), each of them is constructed from 5-50 different values, this means lots of work and lots of maintenance (since these values are both in the DB and in the code)
3. output them as both integers and strings and use a service for lookup values (this is the option I choose):
a. Output the lookup value as string - so it can be displayed to the user (I'm currently not worried about localization issues like the languge of the outputed text)
b. Give out a service that allows clients to receive all possible code/decode values of a lookup - for displaying these options to the user (for example - show a combo containing possible values when creating a new entity).
c. Accept entity input containing integer values for the code of the lookup value, assuming the client decided on the integer code according to the previous mentioned lookup service
This of cours means that I never output my lookup as an enum since there is a problem with consuming enums through WS when all you want is the integer code.
What's your experience with this issue I'd appreciate any input ...
Thanks,
Ido.
passing lookup values out and into services
Ashis Kumar Dutta
Hi Siva,
That's exactly what I did 'till now, with the following additions:
1. Whenever a lookup value is returned, I also return it's description - in case the client just wants the current info without keeping a chached version of all lookups
2. I intend to add in the webservice a description for each lookup parameter that will allow consumers of the service to know to which lookup table this value refers.
Thanks,
Ido.
David Pallmann
I thought enums could serve the purpose for fixed range values such as gender, state. They needn't be in the DB.
Anyway, back to your scenario: Have a service that will give all the value/description pair for a specified lookup type (Gender, State, Status, etc) from the DB. The consumer will fetch these values and cache them locally instead of hitting the service every time; this could also be used to fill drop-downs, lists, etc. Given this, it doesn't matter whether you get list type members as integers or strings - you can lookup one given the other from the local cache. The cache will be updated (i) on a periodic basis (ii) when a value/desc is not found on the local cache.
case123
couple of problems/thoughts regarding your suggestion:
1. Lookup values are usually managed in the DB. Most of the lookup values in most systems are only for display and not for logic, so when they are changed (added/renamed/deleted) in the DB, there is usually no effect on the application.
In you suggestion - every time I change a lookup, I'll need to change the enums and recompile the service - and that's just wrong !!
2. As I've mentioned before, most lookup values are not logic dependant, and in a system that has tens of lookups and just a handfull of them are logic dependant, declaring enums for each and everyone of them just seems wastefull.
3. I haven't checked the following theory (I'll try to find the time this weekend) - Is it possible to declare a typed dataset with columns of enum types and get the correct values when filling the DS with an adapter
Ido.
JimJalinsky
Lance Hunt
Note that once you enable consumers to know the lookup keys they basically become a part of your contract and you cannot change them as easliy as you could when they were just internal values. (esp. since consumers can query the whole Id-value data and cache it... per your suggestion).
What you may need to do as a result of this is to maintain two copies of the lookup tables one for the contract (whcih change slowly) and one internal (which can change more frequently) and map between the two...
Arnon