Re: OO style Webservices or not
- From: "Nicholas Paldino [.NET/C# MVP]" <mvp@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 3 Aug 2005 11:44:22 -0400
Allan,
This is a tricky subject. I think what a good number of people don't
realize is that web services are not OO, and as a result, there is not a lot
of fidelity when trying to map one to the other. Web services are
inherently stateless, while OO is all about the ability to encapsulate state
in an object (or rather, that's a big cornerstone of it).
That being said, I think that your fellow programmer is wrong. Adding
methods with just another name on it will just make things confusing. What
it sounds like you want here is interfaces.
However, you can't really define interfaces on a web service. That
doesn't mean that you can't follow a contract (which is what interfaces are
all about). What you need to do is have each of your web services have the
same method declarations. Then, you place the different implementations of
these method declarations in different directories, so that they have
different URLs (it also makes maintenence of the code easier).
Then, on the client side, you declare your interface. You then generate
web references to each of the different implementations on the server,
creating separate web-proxies.
You can then extend from each of these (since you don't want to play
with IDE-generated code) to implement the interface.
Once you have that, you should have a number of classes that implement
the interface, which you can now use a factory pattern to create (returning
just a reference to the interface).
Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mvp@xxxxxxxxxxxxxxxxxxxxxxxxxxx
"Allan Ebdrup" <comaeb@xxxxxxxx> wrote in message
news:uYHYWaDmFHA.320@xxxxxxxxxxxxxxxxxxxxxxx
>I just had a discussion with one of my fellow programmers.
> We have a class for doing some logging and sending an email, it has 5
> different scenarioes of loggin that are common enough to share a class and
> database tables.
> In the future there might be new scenarioes that require their own custom
> classes and database tables.
>
> Now we want to expose some of our logging class's methods as webservices
> (more a group of function calls called in one batch)
>
> I want to use an OO-like approach to laying out the webservice where we
> have the methods of this one logging class in one .asmx file and create
> other .asmx files for the future logging classes. Then we group all the
> logging .asmx files together in the same namespace (and directory)
>
> He want's to bunch all the Add methods together and have a .AddClass1
> method and a .AddClass2 method and so on in the same .asmx file
>
> What approach is the best? Does one not apply some OO principles to
> webservices (I mean: they are declared as a class with webmethods) or does
> on simply create function libraries with some (hopefully) meaningfull
> grouping of functions.
>
> I hope you have some insights to a best practice for the architecture of
> webservices.
>
> Kind Regards,
> Allan Ebdrup
>
.
- Follow-Ups:
- Re: OO style Webservices or not
- From: Jay B. Harlow [MVP - Outlook]
- Re: OO style Webservices or not
- References:
- OO style Webservices or not
- From: Allan Ebdrup
- OO style Webservices or not
- Prev by Date: Re: OO style Webservices or not
- Next by Date: Re: using Dlls present in remote machine
- Previous by thread: Re: OO style Webservices or not
- Next by thread: Re: OO style Webservices or not
- Index(es):
Relevant Pages
|
