WebService and design arcitecture Questions

[Tal McMahon]

Hello all, I have an Architecture question.

I am building a windows app that will access a SQL server utilizing
web services.

I have several Tables of "look up" type information. i.e. EyeColor,
HairColor, Race etc.

Typically I build Stored procedures to interact with my tables for all
interaction. These procedures are the same for every table. again an
example EyeColorList, EyeColor Edit, EyeColorDelete are exactely the
same as HairColorList,HairColorEdit,and HairColorDelete.

I have built a webservice (asmx page) that will do the updates for any
one of these tables using the select,insert,update,and delete
commandsbuilt into the Dataadapter.

this leads to the question.....Can/should I try to build the
Webservice more generic so that it can dynamically handle all of the
stored procs.

Should I build several sevices one for each table then on the client
Have a helper class that calls the correct one?

What is the best practice for dealing with several (up to 25) parallel
tables that I am doing the Exact same thing from Clent to Web service
to SQL server.

Any Thoughts would be Greatly appreciated.


thanks in advance

Tal McMahon

 

[Dino Chiesa [MSFT]]

Your idea to parameterize the table seems like a good one, because it saves
coding.
In general webservices does not introduce a novel rules for code
paremeterization practices.

I can think of a reason NOT to parameterize the table name: If you need to
NOT disclose the existence of multiple tables.
For example, a webservice like
Updatelist (String tablename)

implies pretty strongly that there are multiple tables out there and invites
probing attacks. But if this is not an issue, then.... why not?