.NET Best Practices for Exposing Biz Objects thru Web Services

[Mark Sisson]

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
practices here? Should I create a facade class manages all of my web
services methods? In other words, is it a best practice to NOT adorn
my biz objects directly with [WebMethod] attributes?

Advantages that I can see:
1. I can control what methods are exposed from underlying biz classes.
2. Biz objects don't need to have extra methods just for public
consumption.
3. The webServiceLayer object could act as a facade when necessary if
needed.
4. Biz objects are reusable and "decoupled" with their web service
front-end

Only disadvantage I can think of:
1. For many methods you may have to retype the biz object's method
signatures into the webServiceLayer class.

Are there any other tips, tricks, or design patterns that people have
for tackling this issue?

TIA
mark

 

[Dino Chiesa [Microsoft]]

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

 

[Jeffrey Hasan]

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.

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
practices here? Should I create a facade class manages all of my web
services methods? In other words, is it a best practice to NOT adorn
my biz objects directly with [WebMethod] attributes?

Advantages that I can see:
1. I can control what methods are exposed from underlying biz classes.
2. Biz objects don't need to have extra methods just for public
consumption.
3. The webServiceLayer object could act as a facade when necessary if
needed.
4. Biz objects are reusable and "decoupled" with their web service
front-end

Only disadvantage I can think of:
1. For many methods you may have to retype the biz object's method
signatures into the webServiceLayer class.

Are there any other tips, tricks, or design patterns that people have
for tackling this issue?

TIA
mark