Wrox Programmer Forums

Need to download code?

View our list of code downloads.

| FAQ | Members List | Search | Today's Posts | Mark Forums Read
BOOK: ASP.NET 2.0 Website Programming Problem Design Solution ISBN: 978-0-7645-8464-0
This is the forum to discuss the Wrox book ASP.NET 2.0 Website Programming: Problem - Design - Solution by Marco Bellinaso; ISBN: 9780764584640
Welcome to the p2p.wrox.com Forums.

You are currently viewing the BOOK: ASP.NET 2.0 Website Programming Problem Design Solution ISBN: 978-0-7645-8464-0 section of the Wrox Programmer to Programmer discussions. This is a community of tens of thousands of software programmers and website developers including Wrox book authors and readers. As a guest, you can read any forum posting. By joining today you can post your own programming questions, respond to other developers’ questions, and eliminate the ads that are displayed to guests. Registration is fast, simple and absolutely free .
DRM-free e-books 300x50
 
 
Thread Tools Search this Thread Display Modes
  #1 (permalink)  
Old February 12th, 2008, 12:29 AM
Authorized User
 
Join Date: Jul 2007
Location: , , .
Posts: 17
Thanks: 0
Thanked 0 Times in 0 Posts
Default Transparent Business Layer

I am working on a project where the lead developer is advocating removing all of the properties from the business layer and making it 'transparent' (using it solely as a means of calling data layer methods). Instead of binding the UI controls to the business layer, he is binding the controls directly to the entity objects themselves. It seems he has taken most of the 'support methods' and lazy-load properties from the business layer and moved them to the entity layer. As a result the business layer's only purpose is to call the DAL methods and return entity objects to the UI controls.

Is there anything lost or gained by this approach, as compared to limiting the entity objects to strictly private fields and properties?

  #2 (permalink)  
Old February 12th, 2008, 03:34 PM
Lee Dumond's Avatar
Wrox Author
Points: 4,942, Level: 29
Points: 4,942, Level: 29 Points: 4,942, Level: 29 Points: 4,942, Level: 29
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Jan 2008
Location: Decatur, IL, USA.
Posts: 923
Thanks: 12
Thanked 166 Times in 162 Posts
Default

I guess I'm not understanding the question exactly. Can you provide an example of any kind to illustrate what you mean?

  #3 (permalink)  
Old February 12th, 2008, 03:40 PM
Authorized User
 
Join Date: Jul 2007
Location: , , .
Posts: 17
Thanks: 0
Thanked 0 Times in 0 Posts
Default

In the book we bind UI controls directly to business objects. These business objects have methods and their properties are loaded through a process of converting entity objects into a business object.

How is this different from a framework where the business objects contain only methods (no properties) and instead of converting the entity objects into business objects, these business methods just pass the entity objects themselves directly to the UI controls instead of first converting them to business objects?

  #4 (permalink)  
Old February 12th, 2008, 04:20 PM
Lee Dumond's Avatar
Wrox Author
Points: 4,942, Level: 29
Points: 4,942, Level: 29 Points: 4,942, Level: 29 Points: 4,942, Level: 29
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Jan 2008
Location: Decatur, IL, USA.
Posts: 923
Thanks: 12
Thanked 166 Times in 162 Posts
Default

Okay, I kind of see what you mean now. I think. :D

I have seen apps built this way, where the UI reaches directly into the DAL and uses the entities from there. It's a valid approach, but in my opinion, you lose a lot of the benefits of the n-tier architecture that way.

To a lot of folks, I suppose it seems repetitive to build entities to wrap the database fields, then build business objects that in large part merely represent those entities. But part of the objective of n-tier is the isolation of layers. In other words, the UI only reaches into the BLL, the BLL only reaches into the DAL, and the DAL only reaches into the DB.

Letting the UI "jump over" the BLL into the DAL, to me, partly defeats the purpose of having a BLL in the first place.

Of course, this is only my opinion. Other folks may differ.

  #5 (permalink)  
Old February 14th, 2008, 12:57 PM
Lee Dumond's Avatar
Wrox Author
Points: 4,942, Level: 29
Points: 4,942, Level: 29 Points: 4,942, Level: 29 Points: 4,942, Level: 29
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Jan 2008
Location: Decatur, IL, USA.
Posts: 923
Thanks: 12
Thanked 166 Times in 162 Posts
Default

Anyone else have an opinion on this? I'm curious what you guys think of the architecture pinch is asking about.

  #6 (permalink)  
Old February 17th, 2008, 02:19 AM
Friend of Wrox
 
Join Date: Jun 2003
Location: Atlanta, Georgia, USA.
Posts: 917
Thanks: 0
Thanked 0 Times in 0 Posts
Default

I like the general idea, but I'm a little more radical in my approach. I never like empty wrappers so I don't see a need for a BLL in this case. We need lazy loading but exactly where this occurs is based on the model. Having a stronger set of entity classes is perhaps more consistant with the ORM approach.

The lighter Entity class model is a better fit for SOA. SOA is built on delegation so you don't want to pass heavy classes between services.

Neither ORM nor SOA is friendly to a pure nTier model, which is why nTier is losing a lot of support in recent years. ORM blurs the distinction between BLL and DAL, and SOA is incompatible with nTier because you never lock want to lock yourself down in a vertical hierarchy - it has to be more flat with various services all willing to help each other. You can can have a Data Access Service, and many Business services that consume the Data Access Service, so that seems like nTier. But you may also have more than 1 data service, and the business services may have to work with various data services. So the model becomes flattened. Many services all willing to work together. But SOA is tightly interface driven and you have strict boundaries, so you do have the separation which is what nTier really wanted to give you.

Disclaimer: some people maintain that SOA is actually one possible implementation of nTier, rather than being something different. They are right. But when you say "nTier" it brings certain things to your mind that are not compatible with SOA so I just keep things simple in order to avoid confusion.

As a test of separation we could add a different front-end that is compatible with the same back-end. A WPF Browser Application could bring a new and exciting GUI for users to interact with, while still keeping the same "classic" browser GUI for users who can't support WPF - a little Silverlight will keep them happy!

 


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Handle error from database layer to applican layer khatu_jec ASP.NET 2.0 Basics 1 November 9th, 2008 03:51 PM
Do we need Business Logic Layer.vb files? cJeffreywang ASP.NET 2.0 Professional 12 January 12th, 2008 06:28 AM
Handle Transactions from Business Logic Layer sonishpaul ASP.NET 2.0 Professional 1 December 3rd, 2007 05:52 AM
Question about Business Layer hasanali00 BOOK: ASP.NET Website Programming Problem-Design-Solution 3 March 21st, 2005 06:49 PM
Errors in a business layer bmains ASP.NET 1.x and 2.0 Application Design 1 February 11th, 2005 02:27 PM



All times are GMT -4. The time now is 08:31 AM.


Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
© 2013 John Wiley & Sons, Inc.