"Mark Sisson" <mark@corporatedigital.com> wrote in message
news:88cc4eb9.0407250818.6c54530e@posting.google.com...
> 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]" <dinoch@online.microsoft.com> wrote in message
news:#RlMybDdEHA.384@TK2MSFTNGP10.phx.gbl...
> 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
>
>
>
> "Mark Sisson" <mark@corporatedigital.com> wrote in message
> news:88cc4eb9.0407250818.6c54530e@posting.google.com...
> > 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
>
>