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.

"gnewsgroup" <(E-Mail Removed)> wrote in message
news:b3f653a7-0459-4f9b-afd1-(E-Mail Removed)...

> 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

On Jan 28, 9:39 am, "Mark Rae [MVP]" <m...@markNOSPAMrae.net> wrote:
> "gnewsgroup" <gnewsgr...@gmail.com> wrote in message
>
> news:b3f653a7-0459-4f9b-afd1-(E-Mail Removed)...
>
>
>
> > 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...@markNOSPAMrae.net> wrote:
> "gnewsgroup" <gnewsgr...@gmail.com> wrote in message
>
> news:b3f653a7-0459-4f9b-afd1-(E-Mail Removed)...
>
>
>
> > 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.

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" <(E-Mail Removed)> wrote in message
news:b3f653a7-0459-4f9b-afd1-(E-Mail Removed)...
> 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.

"gnewsgroup" <(E-Mail Removed)> wrote in message
news:f44604a1-d203-4de4-a13b-(E-Mail Removed)...

> 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

//
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" <(E-Mail Removed)> wrote in message
news:f44604a1-d203-4de4-a13b-(E-Mail Removed)...
> On Jan 28, 9:39 am, "Mark Rae [MVP]" <m...@markNOSPAMrae.net> wrote:
>> "gnewsgroup" <gnewsgr...@gmail.com> wrote in message
>>
>> news:b3f653a7-0459-4f9b-afd1-(E-Mail Removed)...
>>
>>
>>
>> > 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...@markNOSPAMrae.net> wrote:
>> "gnewsgroup" <gnewsgr...@gmail.com> wrote in message
>>
>> news:b3f653a7-0459-4f9b-afd1-(E-Mail Removed)...
>>
>>
>>
>> > 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.

On Jan 28, 10:24 am, "Mark Rae [MVP]" <m...@markNOSPAMrae.net> wrote:
> "gnewsgroup" <gnewsgr...@gmail.com> wrote in message
>
> news:f44604a1-d203-4de4-a13b-(E-Mail Removed)...
>
> > 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.

On Jan 28, 10:27 am, "sloan" <sl...@ipass.net> wrote:
> //
> 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.
>

Thanks. I am still researching your blog. I have been intuitively
doing like what you said by putting those methods that return those
stuff in App_Code.

One question though: How can the DAL be completely independent of the
BLL? Don't we have to know what data we need in the BLL and then for
that purpose write a method in DAL that returns that data ?

Please demystify. Thanks.

On Jan 28, 9:39 am, "Mark Rae [MVP]" <m...@markNOSPAMrae.net> wrote:
> "gnewsgroup" <gnewsgr...@gmail.com> wrote in message
>
> news:b3f653a7-0459-4f9b-afd1-(E-Mail Removed)...
>
>
>
> > 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

I guess I am repeating the question I asked sloan: How can the BLL and
DAL be completely independent of each other? Suppose, in (I guess)
the BLL, I need such fields from my database:

CustomerID, FirstName, LastName, Address.

Don't we have to write a method in the DAL that returns a DataTable
(or whatever) that contains such fields? And then some time later, we
decide to add a Phone field in the BLL, then don't we have to modify
the method in the DAL such that the Phone number is included?

See my confusion now? Thanks.

"gnewsgroup" <(E-Mail Removed)> wrote in message
news:d6f40728-edda-45c6-b08d-(E-Mail Removed)...

> One question though: How can the DAL be completely independent of the
> BLL? Don't we have to know what data we need in the BLL and then for
> that purpose write a method in DAL that returns that data ?

No - that's the whole point!

Let's say you have a method in your DAL called FetchDataSet(.....) which
returns an ADO.NET DataSet object.

The FetchDataSet has two arguments: the name of the stored procedure, and a
collection of parameters to pass to the stored procedure. Additionally, it
might accept a connection string as a parameter or a pointer to indicate
which data provider to use if you've implemented a factory pattern. If you
adopt the Microsoft DAAB example, then the FetchDataSet will be a static
method.

Now that you have that method in your DAL, it will work for *any* method in
your BLL which needs to return a DataSet object from the RDBMS, e.g.

DataSet dsCustomers = MyDAL.FetchDataSet("SelectCustomers", colParameters);

DataSet dsProducts = MyDAL.FetchDataSet("SelectProducts", colParamaters);

etc.


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