Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

DAL / BLL why ? how ?

Status
Not open for further replies.

Badgers

Programmer
Nov 20, 2001
187
US
Hi,

I'm constructing a new website and want to gather a few opions on n-tier.

In the past I have created a data access layer, and set parametres in the function to return say a datareader to the presentation layer. Then bound it to a grid for example.

If I constructed a Business Logic Layer, that would talk to the Data access layer and return me a data reader as well, or some other custom object.

I see why you should use a BLL to talk to the DAL, but I don't massivily see the point, can someone fill me in....

What I see is breaking compatibility in two places DAL and BLL if I need to make function param changes...

If someone provides a simple worked examples it would be great.

Cheers


 
Hi,
As far as i am aware the idea is in your business logic layer your objects are mapped specifically to business entities and the functions associated with them.

Your data access layer has objects mapped to your database entities. The two are not the same.

Also if business logic changes are needed you only need to deal with it in your business layer.

This could help:


"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning."
Rick Cook, The Wizardry Compiled
 
It's a paradigm shift between CRUD (create, read, update, delete) operations and DDD (domain driven design). the DAL should have 1 purpose. Map database fields to a business entity (part of the domain model).

The domain model doesn't care where the objects come from, or how it is presented to the client. It only cares about how the business entities interact with one another. If you use alot of stored procs, or sql functions within your queries then this is the kind of functionality that should exist in the domain, not the sql.

I highly recommend the book Domain Driven Design by Eric Evans. this book focuses on why a rich domain model should be the corner stone of every project.

having a domain model also adhears to the SRP (single responsiblity principle). Which states an object should have exactly one reason to change.
On a macro level this means each "layer" of the application should have 1 responsibility.
GUI: display information
BLL: manage interaction between business entities
DAL: map the business entities to the database and vice verasa
At a micro (code) level this means each object (and even each method) should have one responsibility.

forum678 is a excellent forum to discuss this futher. It's my favorite forum on the site!


Jason Meckley
Programmer
Specialty Bakers, Inc.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top