Dino Chiesa [MSFT]
7/18/2003 11:04:00 PM
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?
"Tal McMahon" <talm@report-software.com> wrote in message
news:7e0e2e21.0307180710.43cce390@posting.google.com...
> 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