It depends on how many application layers you will implement and how often
you will be adding new webservices & functionallity to the system, not to
mention personal preference :)
You could go to extremes and have a single method with parametrized
method-to-call-name, object-input and object-return, (e.g. public object
DoSomething(str ing methodName, object input)) and figure out what to do in
the back, as some data access layers are built. But that's really going to
extremes and requires extra layers with actual methods in front and begind
the ws. It is justified sometimes, though; as always it depends on the
problem.
In a relatively fixed-spec scenario I personally go for object-like
webservices - more services, with fewer methods, just like you normally
build different objects with their respective methods.
This means you need to have several ws references on the client (one ws -
one reference), but it is no biggie and you also have better control. You
can either generate proxies in VS, or manually via the wsdl tool
(e.g. wsdl /out:WSObresti.c s
/namespace:Rrc.D ursNet.Obresti. UI.WSObrestiCli ent
http://localhost/durs/WSObresti/WSObresti.asmx)
The only gripe about this is that objects suddenly come from different
namespaces, so some typecasting is usually involved.
In either scenario I would recommend an intermediate layer on the client, so
that changes to the transport mechanism and webservices need not affect the
client directly. It's not that much work, but may save you plenty of nerves
in the future.
I also recommend that you store the ws urls into the config file of some
sorts (you then target the ws at appropriate urls in the intermediate
layer), so you don't have to recompile the app if you move your webservices
around.
Another thought... if you are transferring your own objects, take a good
look into xml & soap serialization. If you need functionallity only binary
serialization can provide, serialize the objects via binary serializer and
transfer them as byte arrays, then deserialize them back at the client.
Good luck!
Regards,
Sigmund Jakhel
MCSD.NET
"Ryan Wade" <Ryan
Wa**@discussion s.microsoft.com> wrote in message
news:DC******** *************** ***********@mic rosoft.com...
I am very new to web services and I am creating a thin-client windows app
that will access it's data via web services whether on a remote web site
of
on an intranet server. What are the best practices for creating web
services
like this? I will create my own objects and pass them through the web
services(s). Should I use 1 web service with many functions or many web
services with few functions? If I use many web services do I have to add a
web reference in my project to all of them or just one?
