BLL & DAL: How are they different?

[gnewsgroup]

First, just in case, BLL = Business Logic Layer and DAL = Data Access
Layer.

I guess this is really a question about architecture. I believe there
are many architect here.

Software architecture is sorta new to me. I searched a little and did
find this:

http://www.velocityreviews.com/forum...l-and-dal.html

It helped me understand a little bit about their differences and the
advantages of separating them. And now I do have one simple
question:

How do I know what needs to go to the BLL and what needs to go to the
DAL?

My guess is this: Any method that needs to do something like
connection.Open() and use a Sql command (including stored procedure)
should go into the DAL, right? Or is this a principle too naive in
software architecture?

Thanks for sharing your insights into this question.

[Mark Rae [MVP]]

"gnewsgroup" <gn********@gmail.comwrote in message
news:b3**********************************@e23g2000 prf.googlegroups.com...

First, just in case, BLL = Business Logic Layer and DAL = Data Access
Layer.

I guess this is really a question about architecture. I believe there
are many architect here.

Software architecture is sorta new to me. I searched a little and did
find this:

http://www.velocityreviews.com/forum...l-and-dal.html

It helped me understand a little bit about their differences and the
advantages of separating them. And now I do have one simple
question:

How do I know what needs to go to the BLL and what needs to go to the
DAL?

My guess is this: Any method that needs to do something like
connection.Open() and use a Sql command (including stored procedure)
should go into the DAL, right? Or is this a principle too naive in
software architecture?

Not really, though stored procedures won't be in the DAL because they are
RDBMS objects...

Here's an easy (though perhaps over-simplistic) way to think of it.

Project A, Project B and Project C are all totally different, but they all
use SQL Server as their RDBMS. Therefore, they will all have different BLL
but can share the same DAL.

Project D, on the other hand, supports multiple RDBMS. Therefore, it might
have the same DAL as the Projects A, B & C, plus additional DALs which
support Oracle, MySQL, Postgre etc. Alternatively, it may have a single DAL
which supports multiple backend RDBMS through a factory pattern.

Essentially, the BLL and DAL should be completely independent to the extent
that you are able to change one of them without needing to change the
other...
--
Mark Rae
ASP.NET MVP
http://www.markrae.net

[gnewsgroup]

On Jan 28, 9:39 am, "Mark Rae [MVP]" <[e-mail]:

"gnewsgroup" <[e-mail] in message

news:b3**********************************@e23g2000 prf.googlegroups.com...

First, just in case, BLL = Business Logic Layer and DAL = Data Access
Layer.

I guess this is really a question about architecture. I believe there
are many architect here.

Software architecture is sorta new to me. I searched a little and did
find this:

http://www.velocityreviews.com/forum...l-and-dal.html

It helped me understand a little bit about their differences and the
advantages of separating them. And now I do have one simple
question:

How do I know what needs to go to the BLL and what needs to go to the
DAL?

My guess is this: Any method that needs to do something like
connection.Open() and use a Sql command (including stored procedure)
should go into the DAL, right? Or is this a principle too naive in
software architecture?

Not really, though stored procedures won't be in the DAL because they are
RDBMS objects...

Here's an easy (though perhaps over-simplistic) way to think of it.

Project A, Project B and Project C are all totally different, but they all
use SQL Server as their RDBMS. Therefore, they will all have different BLL
but can share the same DAL.

Project D, on the other hand, supports multiple RDBMS. Therefore, it might
have the same DAL as the Projects A, B & C, plus additional DALs which
support Oracle, MySQL, Postgre etc. Alternatively, it may have a single DAL
which supports multiple backend RDBMS through a factory pattern.

Essentially, the BLL and DAL should be completely independent to the extent
that you are able to change one of them without needing to change the
other...

--
Mark Rae
ASP.NET MVPhttp://www.markrae.net

On Jan 28, 9:39 am, "Mark Rae [MVP]" <[e-mail]:

"gnewsgroup" <[e-mail] in message

news:b3**********************************@e23g2000 prf.googlegroups.com...

First, just in case, BLL = Business Logic Layer and DAL = Data Access
Layer.

I guess this is really a question about architecture. I believe there
are many architect here.

Software architecture is sorta new to me. I searched a little and did
find this:

http://www.velocityreviews.com/forum...l-and-dal.html

It helped me understand a little bit about their differences and the
advantages of separating them. And now I do have one simple
question:

How do I know what needs to go to the BLL and what needs to go to the
DAL?

My guess is this: Any method that needs to do something like
connection.Open() and use a Sql command (including stored procedure)
should go into the DAL, right? Or is this a principle too naive in
software architecture?

Not really, though stored procedures won't be in the DAL because they are
RDBMS objects...

Here's an easy (though perhaps over-simplistic) way to think of it.

Project A, Project B and Project C are all totally different, but they all
use SQL Server as their RDBMS. Therefore, they will all have different BLL
but can share the same DAL.

Project D, on the other hand, supports multiple RDBMS. Therefore, it might
have the same DAL as the Projects A, B & C, plus additional DALs which
support Oracle, MySQL, Postgre etc. Alternatively, it may have a single DAL
which supports multiple backend RDBMS through a factory pattern.

Essentially, the BLL and DAL should be completely independent to the extent
that you are able to change one of them without needing to change the
other...

--
Mark Rae
ASP.NET MVPhttp://www.markrae.net

Thank you. I understand that there are a lot of advantages of
separating them. But I am still not sure what goes into the BLL, and
what goes into the DAL. Sounds like both layers can *rightfully*
access the database? Any hint? Thanks.

[sloan]

See:

http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!139.entry
I have a 2.0 version of the blog entry/code as well.

http://sholliday.spaces.live.com/Blog/
My rule of thumb is that the DAL returns:
1. DataSets
2. IDataReaders
3. Scalars
4. Voids/Nothings

You can read the why at the blog.

PS
Read the "bird's eye" view MS article I provide a URL to as well.


"gnewsgroup" <gn********@gmail.comwrote in message
news:b3**********************************@e23g2000 prf.googlegroups.com...

First, just in case, BLL = Business Logic Layer and DAL = Data Access
Layer.

I guess this is really a question about architecture. I believe there
are many architect here.

Software architecture is sorta new to me. I searched a little and did
find this:

http://www.velocityreviews.com/forum...l-and-dal.html

It helped me understand a little bit about their differences and the
advantages of separating them. And now I do have one simple
question:

How do I know what needs to go to the BLL and what needs to go to the
DAL?

My guess is this: Any method that needs to do something like
connection.Open() and use a Sql command (including stored procedure)
should go into the DAL, right? Or is this a principle too naive in
software architecture?

Thanks for sharing your insights into this question.

[Mark Rae [MVP]]

"gnewsgroup" <gn********@gmail.comwrote in message
news:f4**********************************@q21g2000 hsa.googlegroups.com...

Thank you. I understand that there are a lot of advantages of
separating them. But I am still not sure what goes into the BLL, and
what goes into the DAL. Sounds like both layers can *rightfully*
access the database?

Absolutely not! Only the DAL should access the RDBMS. If the BLL requires
interaction with the RDBMS, it uses the DAL...
--
Mark Rae
ASP.NET MVP
http://www.markrae.net

[sloan]

//
Sounds like both layers can *rightfully*
access the database? //

In my opinion:

NO.
The DAL talks to the DB.

The BAL talks to the DAL. Using the 4 things I mention at my blog (the
"returns" from the DAL), you can get what you need done.
And you're safe if you ever need to change RDBMS's.


"gnewsgroup" <gn********@gmail.comwrote in message
news:f4**********************************@q21g2000 hsa.googlegroups.com...

On Jan 28, 9:39 am, "Mark Rae [MVP]" <[e-mail]:

>"gnewsgroup" <[e-mail] in message

news:b3**********************************@e23g200 0prf.googlegroups.com...

First, just in case, BLL = Business Logic Layer and DAL = Data Access
Layer.

I guess this is really a question about architecture. I believe there
are many architect here.

Software architecture is sorta new to me. I searched a little and did
find this:

>http://www.velocityreviews.com/forum...l-and-dal.html

It helped me understand a little bit about their differences and the
advantages of separating them. And now I do have one simple
question:

How do I know what needs to go to the BLL and what needs to go to the
DAL?

My guess is this: Any method that needs to do something like
connection.Open() and use a Sql command (including stored procedure)
should go into the DAL, right? Or is this a principle too naive in
software architecture?

Not really, though stored procedures won't be in the DAL because they are
RDBMS objects...

Here's an easy (though perhaps over-simplistic) way to think of it.

Project A, Project B and Project C are all totally different, but they
all
use SQL Server as their RDBMS. Therefore, they will all have different
BLL
but can share the same DAL.

Project D, on the other hand, supports multiple RDBMS. Therefore, it
might
have the same DAL as the Projects A, B & C, plus additional DALs which
support Oracle, MySQL, Postgre etc. Alternatively, it may have a single
DAL
which supports multiple backend RDBMS through a factory pattern.

Essentially, the BLL and DAL should be completely independent to the
extent
that you are able to change one of them without needing to change the
other...

--
Mark Rae
ASP.NET MVPhttp://www.markrae.net

On Jan 28, 9:39 am, "Mark Rae [MVP]" <[e-mail]:

>"gnewsgroup" <[e-mail] in message

news:b3**********************************@e23g200 0prf.googlegroups.com...

First, just in case, BLL = Business Logic Layer and DAL = Data Access
Layer.

I guess this is really a question about architecture. I believe there
are many architect here.

Software architecture is sorta new to me. I searched a little and did
find this:

>http://www.velocityreviews.com/forum...l-and-dal.html

It helped me understand a little bit about their differences and the
advantages of separating them. And now I do have one simple
question:

How do I know what needs to go to the BLL and what needs to go to the
DAL?

My guess is this: Any method that needs to do something like
connection.Open() and use a Sql command (including stored procedure)
should go into the DAL, right? Or is this a principle too naive in
software architecture?

Not really, though stored procedures won't be in the DAL because they are
RDBMS objects...

Here's an easy (though perhaps over-simplistic) way to think of it.

Project A, Project B and Project C are all totally different, but they
all
use SQL Server as their RDBMS. Therefore, they will all have different
BLL
but can share the same DAL.

Project D, on the other hand, supports multiple RDBMS. Therefore, it
might
have the same DAL as the Projects A, B & C, plus additional DALs which
support Oracle, MySQL, Postgre etc. Alternatively, it may have a single
DAL
which supports multiple backend RDBMS through a factory pattern.

Essentially, the BLL and DAL should be completely independent to the
extent
that you are able to change one of them without needing to change the
other...

--
Mark Rae
ASP.NET MVPhttp://www.markrae.net

Thank you. I understand that there are a lot of advantages of
separating them. But I am still not sure what goes into the BLL, and
what goes into the DAL. Sounds like both layers can *rightfully*
access the database? Any hint? Thanks.

[gnewsgroup]

On Jan 28, 10:24 am, "Mark Rae [MVP]" <[e-mail]:

"gnewsgroup" <[e-mail] in message

news:f4**********************************@q21g2000 hsa.googlegroups.com...

Thank you. I understand that there are a lot of advantages of
separating them. But I am still not sure what goes into the BLL, and
what goes into the DAL. Sounds like both layers can *rightfully*
access the database?

Absolutely not! Only the DAL should access the RDBMS. If the BLL requires
interaction with the RDBMS, it uses the DAL...

--
Mark Rae
ASP.NET MVPhttp://www.markrae.net

Fantastic, that sorta demystifies my confusion. Then, I have actually
been intuitively separating them in my web application. I've put most
methods that return DataTable, SqlDataReader, DataSet and those that
do insert, delete, update under App_Code.

Next question: Are event handlers considered in the presentation
layer? Should the code-behind file contain only event handlers and
everything else should go to either the BLL or DAL?

Thanks again.

[Mark Rae [MVP]]

"Scott Roberts" <sr******@no.spam.here-webworks-software.comwrote in
message news:e4**************@TK2MSFTNGP02.phx.gbl...

What have you really gained here? The ability to swap out SqlClient for
OracleClient? I guess that's nice, but IMO doesn't go far enough.

Like I said in my first reply, this is a very simplistic explanation of BLL
and DAL...
--
Mark Rae
ASP.NET MVP
http://www.markrae.net

[Mark Rae [MVP]]

<zh****@gmail.comwrote in message
news:d6**********************************@1g2000hs l.googlegroups.com...

Question: I suppose colParamaters should always be an array of string,
such that when we add more parameters to a stored procedure in the
RDBMS, we don't have to modify the code in the DAL, right?

Depends on the RDBMS but, for SQL Server, I use the SqlParameters
collection:
http://www.google.co.uk/search?sourc...=SqlParameters

BTW, do DAL mostly have static methods?

Depends... The Microsoft DAAB does, and mine does because I based it on the
Microsoft one...
--
Mark Rae
ASP.NET MVP
http://www.markrae.net

[Mark Rae [MVP]]

<ch*******@yahoo.comwrote in message
news:de**********************************@e6g2000p rf.googlegroups.com...

The DAL is usually a wrapper for the stored procedures used in
accessing data from the database. (That is if you are a stored proc
person).

And what if you aren't a stored procedure person...?

Your DAL might look like this:

public static DataTable GetStockDetails(DbTransaction tran, object SD_SRN)

That's precisely what your DAL *shouldn't* look like!

The DAL should not contain any reference to specific business logic, in this
case stock details.
--
Mark Rae
ASP.NET MVP
http://www.markrae.net

[Scott Roberts]

>There is still a relatively tight coupling between the BLL and the RDBMS

>(even though there is a DAL in the middle). The only way to mitigate this
"problem" is with a DAL mapping scheme (or, my preference, an Object
Persistence Framework). Of course, this adds untold complexity to the DAL
and should not be embarked upon lightly. However, there are several 3rd
party DALs out there that do precisely this, and I hold out hope that
LinqToSql will be another viable option.

Thanks for making it clearer. When I said "I got an idea", I was
thinking to myself "Oh, so the BLL isn't really independent from the
Data layer at least." Exactly like what you said, there is still a
coupling btwn the BLL and the RDBMS.

Well, the only way to completely avoid coupling the BLL and RDBMS is to make
your RDBMS so generic that it is essentially useless outside of your
application. I've considered doing just that in the past, but it seems a bit
extreme and I admit, I like to peek directly into the DB. Not to mention
that most reporting tools utilize direct DB access as well.

So there is almost always *some* coupling. The question is, how much? I
guess that ultimately depends on your situation.

[Mark Rae [MVP]]

"Chris Shepherd" <ch**@nospam.chsh.cawrote in message
news:Om**************@TK2MSFTNGP02.phx.gbl...

How do you manage shifts between database servers or even other storage
mediums (webservices, etc.) with this though?

Factory pattern...

IMO this is contrary to the purpose of abstraction as you are placing Data
Access implementation details inside your BLL.

My BLL interfaces with my DAL, never directly with the RDBMS...

It's great if you only have one place in your BLL where that data is
accessed,

??? My BLL interfaces with my DAL all over the place - everywhere it needs
to, in fact...

but what about cases where you need a different solution to retrieve your
data

Factory pattern...
--
Mark Rae
ASP.NET MVP
http://www.markrae.net