Re: .NET Best Practices for Exposing Biz Objects thru Web Services
From: Jeffrey Hasan (jeff_at_noreply.com)
Date: 08/02/04
- Next message: Jeffrey Hasan: "Re: WSE 2.0 SP1 SoapClient/Service and NAT"
- Previous message: MGRIDEOUT: "Database Connection Object"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 2 Aug 2004 15:18:30 -0700
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
"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
>
>
- Next message: Jeffrey Hasan: "Re: WSE 2.0 SP1 SoapClient/Service and NAT"
- Previous message: MGRIDEOUT: "Database Connection Object"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
