Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / ASP.NET / Web Services / August 2004

Tip: Looking for answers? Try searching our database.

.NET Best Practices for Exposing Biz Objects thru Web Services

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Mark Sisson - 25 Jul 2004 17:18 GMT
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] - 28 Jul 2004 01:07 GMT
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

Rate this thread:







Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.