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********@gma il.comwrote in message
news:b3******** *************** ***********@e23 g2000prf.google groups.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]" <m...@markNOSPA Mrae.netwrote:

"gnewsgroup " <gnewsgr...@gma il.comwrote in message

news:b3******** *************** ***********@e23 g2000prf.google groups.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]" <m...@markNOSPA Mrae.netwrote:

"gnewsgroup " <gnewsgr...@gma il.comwrote in message

news:b3******** *************** ***********@e23 g2000prf.google groups.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.space s.live.com/Blog/cns!A68482B9628 A842A!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********@gma il.comwrote in message
news:b3******** *************** ***********@e23 g2000prf.google groups.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********@gma il.comwrote in message
news:f4******** *************** ***********@q21 g2000hsa.google groups.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********@gma il.comwrote in message
news:f4******** *************** ***********@q21 g2000hsa.google groups.com...

On Jan 28, 9:39 am, "Mark Rae [MVP]" <m...@markNOSPA Mrae.netwrote:

>"gnewsgroup " <gnewsgr...@gma il.comwrote in message

news:b3******* *************** ************@e2 3g2000prf.googl egroups.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]" <m...@markNOSPA Mrae.netwrote:

>"gnewsgroup " <gnewsgr...@gma il.comwrote in message

news:b3******* *************** ************@e2 3g2000prf.googl egroups.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]" <m...@markNOSPA Mrae.netwrote:

"gnewsgroup " <gnewsgr...@gma il.comwrote in message

news:f4******** *************** ***********@q21 g2000hsa.google groups.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.sp am.here-webworks-software.comwro te in
message news:e4******** ******@TK2MSFTN GP02.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.c omwrote in message
news:d6******** *************** ***********@1g2 000hsl.googlegr oups.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*******@yaho o.comwrote in message
news:de******** *************** ***********@e6g 2000prf.googleg roups.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