YES
use a Facade, please.
At the webservice layer you get to add in interface-centric function, like
- auditing, logging, data collection
- authorization checking
- caching, optimization, request bundling, prioritization
- re-direction
- version control
The disadvantage you mentioned - yes, it's true it is yet more code to build
and maintain, which is always bad. So there is a threshold above which the
webservice layer makes sense. The tricky $64 question is, where is that
threshold? and THAT is a matter of great debate.
If the business layer is a matter of 10 objects, then maybe a facade is too
much work. If the transaction volume is in the 100's per week, then you
don't need the complexity.
At the other end of the scale, if there are hundreds of objects and perhaps
thousands of concurrent instances. Or if the transaction volume is in the
millions per day, or even hundreds of thousands per day, then you will want
the extra control and flexibility that an additional layer brings.
In between these extremes is where most applications lie, and so as always,
the answer to the question of whether or not to add the extra architectural
artifact is...
maybe.
-D
> I'm architecting some business objects in .NET and want to expose some
> methods from my biz objects via Web Services. What are the best
[quoted text clipped - 20 lines]
> TIA
> mark
Jeffrey Hasan - 02 Aug 2004 23:18 GMT
You can minimize the retyping by abstracting the business object interface
out to a separate file. You can then reference this interface file in the
Web service code-behind (as well as in the business object of course).
Jeffrey Hasan, MCSD
President, Bluestone Partners, Inc.
-----------------------------------------------
Author of: Expert SOA in C# Using WSE 2.0 (APress, 2004)
http://www.bluestonepartners.com/soa.aspx
> YES
> use a Facade, please.
[quoted text clipped - 51 lines]
> > TIA
> > mark