BLL & DAL: How are they different?

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/forums/t300246-bll-and-dal.ht ml

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.

Re: BLL & DAL: How are they different?

"gnewsgroup" wrote in message
news:b3f653a7-0459-4f9b-afd1-ffa899da0b00@e23g2000prf.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/forums/t300246-bll-and-dal.ht ml
>
> 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

Re: BLL & DAL: How are they different?

On Jan 28, 9:39 am, "Mark Rae [MVP]" wrote:
> "gnewsgroup" wrote in message
>
> news:b3f653a7-0459-4f9b-afd1-ffa899da0b00@e23g2000prf.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/forums/t300246-bll-and-dal.h tml
>
> > 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]" wrote:
> "gnewsgroup" wrote in message
>
> news:b3f653a7-0459-4f9b-afd1-ffa899da0b00@e23g2000prf.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/forums/t300246-bll-and-dal.h tml
>
> > 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.

Re: BLL & DAL: How are they different?

See:

http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!1 39.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" wrote in message
news:b3f653a7-0459-4f9b-afd1-ffa899da0b00@e23g2000prf.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/forums/t300246-bll-and-dal.ht ml
>
> 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.

Re: BLL & DAL: How are they different?

"gnewsgroup" wrote in message
news:f44604a1-d203-4de4-a13b-34b5917ba671@q21g2000hsa.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

Re: BLL & DAL: How are they different?

//
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" wrote in message
news:f44604a1-d203-4de4-a13b-34b5917ba671@q21g2000hsa.google groups.com...
> On Jan 28, 9:39 am, "Mark Rae [MVP]" wrote:
>> "gnewsgroup" wrote in message
>>
>> news:b3f653a7-0459-4f9b-afd1-ffa899da0b00@e23g2000prf.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/forums/t300246-bll-and-dal.h tml
>>
>> > 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]" wrote:
>> "gnewsgroup" wrote in message
>>
>> news:b3f653a7-0459-4f9b-afd1-ffa899da0b00@e23g2000prf.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/forums/t300246-bll-and-dal.h tml
>>
>> > 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.

Re: BLL & DAL: How are they different?

On Jan 28, 10:24 am, "Mark Rae [MVP]" wrote:
> "gnewsgroup" wrote in message
>
> news:f44604a1-d203-4de4-a13b-34b5917ba671@q21g2000hsa.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.

Re: BLL & DAL: How are they different?

On Jan 28, 10:27 am, "sloan" 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.

Re: BLL & DAL: How are they different?

On Jan 28, 9:39 am, "Mark Rae [MVP]" wrote:
> "gnewsgroup" wrote in message
>
> news:b3f653a7-0459-4f9b-afd1-ffa899da0b00@e23g2000prf.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/forums/t300246-bll-and-dal.h tml
>
> > 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.

Re: BLL & DAL: How are they different?

"gnewsgroup" wrote in message
news:d6f40728-edda-45c6-b08d-e6fa31007c97@k39g2000hsf.google groups.com...

> 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

Re: BLL & DAL: How are they different?

"gnewsgroup" wrote in message
news:3870c25a-2400-4380-8981-c6371ae15a5e@p69g2000hsa.google groups.com...

> 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:

See my reply of about a minute ago...

> 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?

No - you simply modify the stored procedure!

> See my confusion now?

No.


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

Re: BLL & DAL: How are they different?

Consider layers just like real life abstraction. Let me give an
example of Automobile, a bus. The color of Bus, quality of seats, A/C
etc are presentation layers. The controls what driver uses like
breaks, steering wheel consider like Business Logic Layer. Further
details like how Engine or breaks works internally consider like Data
Access layer.

A person taking ride on bus as customer just sees outlook. Doesn't
need to know how bus is driven etc. A driver just need to know how
well bus is controlled and doesn't need to know internals of engines.
A mechanic although must know how to fix malfunctioning breaks etc.

As you see if engine isn't working, driver can't use bus. Thus to
function BLL properly DAL must work. The information is passed between
them through some known protocol. If engine is replaced by another
engine driver shouldn't feel any difference in operating controls.
There should be common way to work a BLL on various DAL with a common
interface.

Coming back to programming. DAL should deal with all code for SQL or
stored procedure. Must have inheritance where common aspects are on
base class and derived class implementation of each database or
otherwise. e.g. Various sub classes to handle SQL Server, Oracle,
etc.

BLL should have calculations for any business specifics. e.g. forumla
for interest in banking application. If you decided to calculate
interest as compound instead of simple interest, you should just
change BLL and not DLL. It would be bad design to save balance and
interest forumla in DAL and requiring changes in all DAL classes.

Final million dollar question is how to pass infomration between BLL
and DAL and vice versa. This is profound question with two answers
in .net, Customized objects and typed dataset. Dissucssion of this
beyond scope of this post. Google for "Customized objects vs typed
dataset" and hope you will get input from experts.

regards,
radix.






On Jan 28, 10:56 am, gnewsgroup wrote:
> On Jan 28, 10:27 am, "sloan" 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.

Re: BLL & DAL: How are they different?

If you look at my blog, I handle this through "Layouts".
Although I use IDataReaders primarily.

...

When I need to add a new field...I change the

TSQL ( stored procedure)
the "Layout"

The Serializer, which converts the IDataReader to the business object and/or
collection.

...

If you're using strong datasets, or single datatables..you should only have
to change

TSQL
Add the column to the datatable/strong dataset.

Depending on which load mechanism you're using to push data from a stored
procedure into a datatable (or strong dataset).

...


"gnewsgroup" wrote in message
news:3870c25a-2400-4380-8981-c6371ae15a5e@p69g2000hsa.google groups.com...
> On Jan 28, 9:39 am, "Mark Rae [MVP]" wrote:
>> "gnewsgroup" wrote in message
>>
>> news:b3f653a7-0459-4f9b-afd1-ffa899da0b00@e23g2000prf.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/forums/t300246-bll-and-dal.h tml
>>
>> > 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.

Re: BLL & DAL: How are they different?

On Jan 28, 11:11 am, "Mark Rae [MVP]" wrote:
> "gnewsgroup" wrote in message
>
> news:d6f40728-edda-45c6-b08d-e6fa31007c97@k39g2000hsf.google groups.com...
>
> > 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 MVPhttp://www.markrae.net

Again, fantastic. I do have some methods in some classes under
App_Code that take the name of a stored procedure and the parameters
the stored procedure takes. I did not know that I was separating DAL
from BLL, my intention was to be able to have more generickish methods
(to avoid writing very similar methods one after another) to call in
my code-behind.

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?

BTW, do DAL mostly have static methods? Thanks once again.

Re: BLL & DAL: How are they different?

"Mark Rae [MVP]" wrote in message
news:e7Ua5hcYIHA.3964@TK2MSFTNGP03.phx.gbl...
> "gnewsgroup" wrote in message
> news:d6f40728-edda-45c6-b08d-e6fa31007c97@k39g2000hsf.google groups.com...
>
>> 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);

Interesting.

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. You still
have a very tight coupling between your BLL and RDBMS. Do you rely on the
BLL to interpret/decouple the data? I'd say that belongs in the DAL.

Re: BLL & DAL: How are they different?

On Jan 28, 11:11=A0am, "Mark Rae [MVP]" wrote:
> "gnewsgroup" wrote in message
>
> news:d6f40728-edda-45c6-b08d-e6fa31007c97@k39g2000hsf.google groups.com...
>
> > One question though: How can the DAL be completely independent of the
> > BLL? =A0Don'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 i=
n
> your BLL which needs to return a DataSet object from the RDBMS, e.g.
>
> DataSet dsCustomers =3D MyDAL.FetchDataSet("SelectCustomers", colParameter=
s);
>
> DataSet dsProducts =3D MyDAL.FetchDataSet("SelectProducts", colParamaters)=
;
>
> etc.
>
> --
> Mark Rae
> ASP.NET MVPhttp://www.markrae.net

Again, fantastic. I do have some methods in some classes under
App_Code that take the name of a stored procedure and the parameters
the stored procedure takes. I did not know that I was separating DAL
from BLL, my intention was to be able to have more generickish methods
(to avoid writing very similar methods one after another) to call in
my code-behind.

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?

BTW, do DAL mostly have static methods? Thanks once again.

Re: BLL & DAL: How are they different?

On Jan 28, 11:19=A0am, "sloan" wrote:
> If you look at my blog, I handle this through "Layouts".
> Although I use IDataReaders primarily.
>
> ..
>
> When I need to add a new field...I change the
>
> TSQL ( stored procedure)
> the "Layout"
>
> The Serializer, which converts the IDataReader to the business object and/=
or
> collection.
>
> ..
>
> If you're using strong datasets, or single datatables..you should only hav=
e
> to change
>
> TSQL
> Add the column to the datatable/strong dataset.
>
> Depending on which load mechanism you're using to push data from a stored
> procedure into a datatable (or strong dataset).
>
> ..
>

So, I suppose, in the method in your DAL, you don't pass the
parameters of a stored procedure one by one, but instead, you pass an
array, such that your method can take a different number of stored
procedure parameters, right?

Re: BLL & DAL: How are they different?

If you're using Strong DataSets or a DataTable model, then

these get defined in their own assembly....and "float" outside of the
others.
They have also been called the "glue" assemblies.

If you get my code, you'll see that my DataSets project resides OUTSIDE of
the other 3 layers.
This is my glue assembly.



My blog has a bad URL, for the "birds eye" article.
Here is the correction.

http://msdn2.microsoft.com/en-us/library/ms978496.aspx

Read that article.
Go to lunch.
Come back and reread that article.
Bookmark it.
In a week, reread that article.


If you find this part of the article:
Deploying Business Entities

You can read...and that is where I'm saying the strong dataset (or now the
DataTable) will reside in its own assembly as a the "glue".
This is the idea presented in the first dotted (lineitem) in the section
labeled "Deploying Business Entities".

...

This is something where you're going to read 1 article and get it by just
reading.
You gotta try and code one up. (Which I know you are doing, and tryign to
find help via this post).
I'm just saying ... you gotta work with it some...and you gotta do some
reading and rereading as you get better with it.

I still read that article about every 6 months.....

You're leaning toward the DataTable/DataSet model. I've converted over to
custom business objects and custom collections.

Both are ok solutions. The article above .... is the best article I've
discovered which outlines the pros and cons of the approches.
That's why its a good "bird's eye view" article.









"gnewsgroup" wrote in message
news:3870c25a-2400-4380-8981-c6371ae15a5e@p69g2000hsa.google groups.com...
> On Jan 28, 9:39 am, "Mark Rae [MVP]" wrote:
>> "gnewsgroup" wrote in message
>>
>> news:b3f653a7-0459-4f9b-afd1-ffa899da0b00@e23g2000prf.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/forums/t300246-bll-and-dal.h tml
>>
>> > 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.

Re: BLL & DAL: How are they different?

On Jan 28, 11:17=A0am, radix wrote:
> Consider layers just like real life abstraction. Let me give an
> example of Automobile, a bus. The color of Bus, quality of seats, A/C
> etc are presentation layers. The controls what driver uses like
> breaks, steering wheel consider like Business Logic Layer. Further
> details like how Engine or breaks works internally consider like Data
> Access layer.
>
> A person taking ride on bus as customer just sees outlook. Doesn't
> need to know how bus is driven etc. A driver just need to know how
> well bus is controlled and doesn't need to know internals of engines.
> A mechanic although must know how to fix malfunctioning breaks etc.
>
> As you see if engine isn't working, driver can't use bus. Thus to
> function BLL properly DAL must work. The information is passed between
> them through some known protocol. If engine is replaced by another
> engine driver shouldn't feel any difference in operating controls.
> There should be common way to work a BLL on various DAL with a common
> interface.
>
> Coming back to programming. DAL should deal with all code for SQL or
> stored procedure. Must have inheritance where common aspects are on
> base class and derived class implementation of each database or
> otherwise. e.g. Various sub classes to handle SQL Server, Oracle,
> etc.
>
> BLL should have calculations for any business specifics. e.g. forumla
> for interest in banking application. If you decided to calculate
> interest as compound instead of simple interest, you should just
> change BLL and not DLL. It would be bad design to save balance and
> interest forumla in DAL and requiring changes in all DAL classes.
>
> Final million dollar question is how to pass infomration between BLL
> and DAL and vice versa. This is profound question with two answers
> in .net, Customized objects and typed dataset. Dissucssion of this
> beyond scope of this post. Google for "Customized objects vs typed
> dataset" and hope =A0you will get input from experts.
>
> regards,
> radix.
>

Thank you very much for the nice example/analogy, which I can reuse in
the future if there is a need. :-) It sounds to me like generic
programming, (not necessarily related to generic collections), in the
sense that we want to make our code generic enough such that when some
component changes, all others don't have to change.

Re: BLL & DAL: How are they different?

//So, I suppose, in the method in your DAL, you don't pass the
parameters of a stored procedure one by one, but instead, you pass an
array, such that your method can take a different number of stored
procedure parameters, right?
//


Huh?

I pass arguments to methods in my DAL.

int employeeID, string lastName, string firstName

....

I don't think you've spent enough time with my example.....

...

To be honest, I don't like the uber super cool ..pass in a bunch of dynamic
parameter type stuff.


So I'll come back tomorrow, and see if you have any specific questions about
my example.

I realize you're on information overload right now.

Spend some time with the example. Run the code....and step through it.

...





"gnewsgroup" wrote in message
news:346cf493-0d47-4470-b905-f2105bc7d7e2@v46g2000hsv.google groups.com...
On Jan 28, 11:19 am, "sloan" wrote:
> If you look at my blog, I handle this through "Layouts".
> Although I use IDataReaders primarily.
>
> ..
>
> When I need to add a new field...I change the
>
> TSQL ( stored procedure)
> the "Layout"
>
> The Serializer, which converts the IDataReader to the business object
> and/or
> collection.
>
> ..
>
> If you're using strong datasets, or single datatables..you should only
> have
> to change
>
> TSQL
> Add the column to the datatable/strong dataset.
>
> Depending on which load mechanism you're using to push data from a stored
> procedure into a datatable (or strong dataset).
>
> ..
>

So, I suppose, in the method in your DAL, you don't pass the
parameters of a stored procedure one by one, but instead, you pass an
array, such that your method can take a different number of stored
procedure parameters, right?

Re: BLL & DAL: How are they different?

On Jan 28, 11:54=A0am, "sloan" wrote:
> If you're using Strong DataSets or a DataTable model, then
>
> these get defined in their own assembly....and "float" outside of the
> others.
> They have also been called the "glue" assemblies.
>
> If you get my code, you'll see that my DataSets project resides OUTSIDE of=

> the other 3 layers.
> This is my glue assembly.
>
> My blog has a bad URL, for the "birds eye" article.
> Here is the correction.
>
> http://msdn2.microsoft.com/en-us/library/ms978496.aspx
>
> Read that article.
> Go to lunch.
> Come back and reread that article.
> Bookmark it.
> In a week, reread that article.
>
> If you find this part of the article:
> Deploying Business Entities
>
> You can read...and that is where I'm saying the strong dataset (or now the=

> DataTable) will reside in its own assembly as a the "glue".
> This is the idea presented in the first dotted (lineitem) in the section
> labeled "Deploying Business Entities".
>
> ..
>
> This is something where you're going to read 1 article and get it by just
> reading.
> You gotta try and code one up. =A0(Which I know you are doing, and tryign =
to
> find help via this post).
> I'm just saying ... you gotta work with it some...and you gotta do some
> reading and rereading as you get better with it.
>
> I still read that article about every 6 months.....
>
> You're leaning toward the DataTable/DataSet model. =A0I've converted over =
to
> custom business objects and custom collections.
>
> Both are ok solutions. =A0The article above .... is the best article I've
> discovered which outlines the pros and cons of the approches.
> That's why its a good "bird's eye view" article.
>

Thank you. The MSDN article has been printed out and your sample code
has been downloaded for research. Will get back if I have questions.

Re: BLL & DAL: How are they different?

"Scott Roberts" wrote in
message news:e4l1s1cYIHA.6140@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

Re: BLL & DAL: How are they different?

wrote in message
news:d6237cfa-f310-4780-b333-063b0a99ffb6@1g2000hsl.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?sourceid=navclient&hl=en-GB&i e=UTF-8&rlz=1T4GZEZ_en-GBGB252GB252&q=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

Re: BLL & DAL: How are they different?

> Final million dollar question is how to pass infomration between BLL
> and DAL and vice versa. This is profound question with two answers
> in .net, Customized objects and typed dataset. Dissucssion of this
> beyond scope of this post. Google for "Customized objects vs typed
> dataset" and hope you will get input from experts.

Do you count LinqToSql under "customized objects"? I haven't gotten to play
with it as much as I would like, but it looks fairly promising as a "bridge"
between those of us in the "customized objects" camp and those in the
"datasets are easier" camp.

Re: BLL & DAL: How are they different?

On Jan 28, 12:20 pm, "Scott Roberts" software.com> wrote:
> > Final million dollar question is how to pass infomration between BLL
> > and DAL and vice versa. This is profound question with two answers
> > in .net, Customized objects and typed dataset. Dissucssion of this
> > beyond scope of this post. Google for "Customized objects vs typed
> > dataset" and hope you will get input from experts.
>
> Do you count LinqToSql under "customized objects"? I haven't gotten to play
> with it as much as I would like, but it looks fairly promising as a "bridge"
> between those of us in the "customized objects" camp and those in the
> "datasets are easier" camp.

Yes. LINQ is very elegant way to avoid duplicate implementation in
DAL. If you are using .net 3.5, I think LINQ should be used.

Re: BLL & DAL: How are they different?

Hello gnewsgroup,

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).

The BLL is contains the business logic and also acts as a wrapper for
accessing
the DAL layer in a 3 -tier architecture model. The presentation layer
then directly accesses
the BLL.

In the architectures above, it is adiceable to access only the layer
beneath it.
The advantages of multi-tier architecture is to allow for easy
maintenance. One layer can
be modified without breaking the other layers or needing to modify
them.

Your DAL might look like this:

using System;
using System.Collections.Generic;
using System.Text;
using System.Data;
using System.Data.Common;
using Microsoft.Practices.EnterpriseLibrary.Data;
//using Microsoft.Practices.EnterpriseLibrary.Data.Sql;


namespace IConceptDBWebUpdate.DAL
{
public class StockDetailDB : DataLayerBase
{

#region GetStockDetails
public static DataTable GetStockDetails(DbTransaction tran,
object SD_SRN)
{
DataTable retVal =3D new DataTable();

Database db =3D DatabaseFactory.CreateDatabase();

DbCommand cmd =3D
db.GetStoredProcCommand("proc_GetStockDetails");

db.AddInParameter(cmd, "@SD_SRN_", DbType.Double, SD_SRN);


retVal =3D ExecuteDataSet(db, tran, cmd).Tables[0];

return retVal;

}
#endregion


while your BLL might look like this:

using System;
using System.Collections.Generic;
using System.Text;
using System.Data;
using System.Data.Common;
using Microsoft.Practices.EnterpriseLibrary.Data;
//using Microsoft.Practices.EnterpriseLibrary.Data.Sql;
using IConceptDBWebUpdate.DAL;

namespace IConceptDBWebUpdate.BLL
{
[System.ComponentModel.DataObject]
public class StockDetail
{
#region GetStockDetails
public static DataTable GetStockDetails(object SD_SRN)
{
return StockDetailDB.GetStockDetails(null, SD_SRN);

}
#endregion

In the code snippets above, I am using the Microsoft Enterprise Lib
DAAB.
You could download it free from the web.

I hope this helps.
Thanks.

Regards,

Chike.


On Jan 28, 10:15=A0pm, radix wrote:
> On Jan 28, 12:20 pm, "Scott Roberts" >
> software.com> wrote:
> > > Final million dollar question is how to pass infomration between BLL
> > > and DAL and vice versa. This is profound question with two answers
> > > in .net, Customized objects and typed dataset. Dissucssion of this
> > > beyond scope of this post. Google for "Customized objects vs typed
> > > dataset" and hope you will get input from experts.
>
> > Do you count LinqToSql under "customized objects"? I haven't gotten to p=
lay
> > with it as much as I would like, but it looks fairly promising as a "bri=
dge"
> > between those of us in the "customized objects" camp and those in the
> > "datasets are easier" camp.
>
> Yes. LINQ is very elegant way to avoid duplicate implementation in
> DAL. If you are using .net 3.5, I think LINQ should be used.

Re: BLL & DAL: How are they different?

wrote in message
news:de4d6bbc-0aa6-4ed2-9117-2b97f6841dcb@e6g2000prf.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

Re: BLL & DAL: How are they different?

On Mon, 28 Jan 2008 08:04:35 -0800 (PST), gnewsgroup
wrote:

>
>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:
>
The confusion is due to the lack of a clean interface between the
app-specific BLL and the theoretically generic DAL.

>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?
>
This depends upon how the DAL actually retrieves the data. Such a
change might be transparent if stored procedures are used.
>See my confusion now? Thanks.
I would define the BLL's desired interface with the DAL as
IBusinessData or such. The implementation of the interface would be an
adapter between the BLL and DAL or it could be a wrapper for the DAL.
Either way the BLL talks to an IBusinessData interface and not
directly to the DAL.

This lets the implementation be malleable based upon the DAL. If the
DAL changes, a new IBusinessData implementation can be created w/out
changing the BLL. The implementation will turn out to be pretty thin.

regards
A.G.

Re: BLL & DAL: How are they different?

On Jan 29, 5:00=A0am, "Mark Rae [MVP]" wrote:
> wrote in message
>
> news:de4d6bbc-0aa6-4ed2-9117-2b97f6841dcb@e6g2000prf.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_SR=
N)
>
> That's precisely what your DAL *shouldn't* look like!
>
> The DAL should not contain any reference to specific business logic, in th=
is
> case stock details.
>
> --
> Mark Rae
> ASP.NET MVPhttp://www.markrae.net

So, the DAL should be abstract enough, so abstract such that one
cannot very well predict what the BLL is roughly doing by looking at
the DAL code only, right? Let's forget about the suggestivity of
stored procedure names which are used in the DAL.

Also, Mark, in your reply dated Jan 28, 12:13pm, you say:

Depends on the RDBMS but, for SQL Server, I use the SqlParameters
collection.

in response to my question:

> 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?

I was wondering if you would have to make changes in your DAL if you
add or leave out a parameter in your stored procedure. After all, in
your DAL, I assume that you still have to contruct the SqlParameter
before you call the stored procedure, right?

Thanks.

Re: BLL & DAL: How are they different?

"gnewsgroup" wrote in message
news:3a261efe-3b67-4fdb-9bcb-b489f80290ba@j78g2000hsd.google groups.com...

>> The DAL should not contain any reference to specific business logic, in
>> this
>> case stock details.
>
>
> So, the DAL should be abstract enough, so abstract such that one
> cannot very well predict what the BLL is roughly doing by looking at
> the DAL code only, right? Let's forget about the suggestivity of
> stored procedure names which are used in the DAL.

IMO, yes. The DAL should be precisely as its name suggests: a layer for
accessing the database - no more, no less.

E.g. supposing you have two completely different projects, both of which use
SQL Server as your RDBMS. So long as your DAL is capable of interfacing with
SQL Server (either because that's the only RDBMS it supports or because it
uses a factory pattern), you should simply be able to drop your DAL into
both projects without modification. If you have to modify it even slightly,
then it's not a DAL, IMO...

> Also, Mark, in your reply dated Jan 28, 12:13pm, you say:
>
> Depends on the RDBMS but, for SQL Server, I use the SqlParameters
> collection.
>
> in response to my question:
>
> 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?
>
> I was wondering if you would have to make changes in your DAL if you
> add or leave out a parameter in your stored procedure.

No you don't! And, at the risk of repeating myself, that's the WHOLE
POINT!!!

> After all, in your DAL, I assume that you still have to contruct the
> SqlParameter
> before you call the stored procedure, right?

No!!! You construct the SqlParameters collection in your BLL and *PASS IT*
to your DAL... E.g.

// method in BLL ---------------------------------

using System;
using System.Collections.Generic;
using System.Data;
using System.Data.SqlClient;

private void BindData()
{
SqlParameter objSqlParameter;
List lobjSqlParameters = new List();

objSqlParameter = new SqlParameter("@ClientID", SqlDbType.Int);
objSqlParameter.Value = Convert.ToInt32(ViewState["SiteID"]);
lobjSqlParameters.Add(objSqlParameter);

objSqlParameter = new SqlParameter("@OrderID", SqlDbType.Int);
objSqlParameter.Value = Convert.ToInt32(ViewState["OrderID"]);
lobjSqlParameters.Add(objSqlParameter);

// add as many more SqlParameter objects as required in the stored procedure

DataSet MyDS = MyDAL.GetDataSet("FetchOrder", lobjSqlParameters);
MyGridView.DataSource = MyDS;
MyGridView.DataBind();
}


// method in DAL -------------------------------

public static DataSet GetDataSet(string pstrSP, List
plstSqlParameters)
{
using (SqlConnection objSqlConnection = new
SqlConnection(mstrConnectionString))
{
objSqlConnection.Open();
using (SqlCommand objSqlCommand = new SqlCommand(pstrSP,
objSqlConnection))
{
objSqlCommand.CommandType = CommandType.StoredProcedure;
foreach (SqlParameter objSqlParameter in plstSqlParameters)
{
objSqlCommand.Parameters.Add(objSqlParameter);
}
using (SqlDataAdapter objDA = new SqlDataAdapter(objSqlCommand))
{
using (DataSet objDataSet = new DataSet())
{
objDA.Fill(objDataSet);
objSqlConnection.Close();
return (objDataSet);
}
}
}
}
}


As I mentioned, the above is just the way I do things... It's not the only
way, nor am I claiming it's the *right* way...


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

Re: BLL & DAL: How are they different?

On Jan 29, 9:31=A0am, "Mark Rae [MVP]" wrote:
> "gnewsgroup" wrote in message
>
> news:3a261efe-3b67-4fdb-9bcb-b489f80290ba@j78g2000hsd.google groups.com...
>
> >> The DAL should not contain any reference to specific business logic, in=

> >> this
> >> case stock details.
>
> > So, the DAL should be abstract enough, so abstract such that one
> > cannot very well predict what the BLL is roughly doing by looking at
> > the DAL code only, right? =A0Let's forget about the suggestivity of
> > stored procedure names which are used in the DAL.
>
> IMO, yes. The DAL should be precisely as its name suggests: a layer for
> accessing the database - no more, no less.
>
> E.g. supposing you have two completely different projects, both of which u=
se
> SQL Server as your RDBMS. So long as your DAL is capable of interfacing wi=
th
> SQL Server (either because that's the only RDBMS it supports or because it=

> uses a factory pattern), you should simply be able to drop your DAL into
> both projects without modification. If you have to modify it even slightly=
,
> then it's not a DAL, IMO...
>
> > Also, Mark, in your reply dated Jan 28, 12:13pm, you say:
>
> > Depends on the RDBMS but, for SQL Server, I use the SqlParameters
> > collection.
>
> > in response to my question:
>
> > 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?
>
> > I was wondering if you would have to make changes in your DAL if you
> > add or leave out a parameter in your stored procedure.
>
> No you don't! And, at the risk of repeating myself, that's the WHOLE
> POINT!!!
>
> > After all, in your DAL, I assume that you still have to contruct the
> > SqlParameter
> > before you call the stored procedure, right?
>
> No!!! You construct the SqlParameters collection in your BLL and *PASS IT*=

> to your DAL... E.g.
>
> // method in BLL ---------------------------------
>
> using System;
> using System.Collections.Generic;
> using System.Data;
> using System.Data.SqlClient;
>
> private void BindData()
> {
> =A0 =A0 SqlParameter objSqlParameter;
> =A0 =A0 List lobjSqlParameters =3D new List();=

>
> =A0 =A0 objSqlParameter =3D new SqlParameter("@ClientID", SqlDbType.Int);
> =A0 =A0 objSqlParameter.Value =3D Convert.ToInt32(ViewState["SiteID"]);
> =A0 =A0 lobjSqlParameters.Add(objSqlParameter);
>
> =A0 =A0 objSqlParameter =3D new SqlParameter("@OrderID", SqlDbType.Int);
> =A0 =A0 objSqlParameter.Value =3D Convert.ToInt32(ViewState["OrderID"]);
> =A0 =A0 lobjSqlParameters.Add(objSqlParameter);
>
> // add as many more SqlParameter objects as required in the stored procedu=
re
>
> =A0 =A0 DataSet MyDS =3D MyDAL.GetDataSet("FetchOrder", lobjSqlParameters)=
;
> =A0 =A0 MyGridView.DataSource =3D MyDS;
> =A0 =A0 MyGridView.DataBind();
>
> }
>
> // method in DAL -------------------------------
>
> public static DataSet GetDataSet(string pstrSP, List
> plstSqlParameters)
> {
> =A0 =A0 using (SqlConnection objSqlConnection =3D new
> SqlConnection(mstrConnectionString))
> =A0 =A0 {
> =A0 =A0 =A0 =A0 objSqlConnection.Open();
> =A0 =A0 =A0 =A0 using (SqlCommand objSqlCommand =3D new SqlCommand(pstrSP,=

> objSqlConnection))
> =A0 =A0 =A0 =A0 {
> =A0 =A0 =A0 =A0 =A0 =A0 objSqlCommand.CommandType =3D CommandType.StoredPr=
ocedure;
> =A0 =A0 =A0 =A0 =A0 =A0 foreach (SqlParameter objSqlParameter in plstSqlPa=
rameters)
> =A0 =A0 =A0 =A0 =A0 =A0 {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 objSqlCommand.Parameters.Add(objSqlParamet=
er);
> =A0 =A0 =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 =A0 =A0 using (SqlDataAdapter objDA =3D new SqlDataAdapter=
(objSqlCommand))
> =A0 =A0 =A0 =A0 =A0 =A0 {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 using (DataSet objDataSet =3D new DataSet(=
))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 objDA.Fill(objDataSet);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 objSqlConnection.Close();
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (objDataSet);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 }
> =A0 =A0 }
>
> }
>
> As I mentioned, the above is just the way I do things... It's not the only=

> way, nor am I claiming it's the *right* way...
>
> --
> Mark Rae
> ASP.NET MVPhttp://www.markrae.net

Thank you and I understand then that no changes need to be made in the
DAL after we make changes to the stored procedure, but, it seems that
the BLL still needs to know about the parameter change in the stored
procedure in order to construct the SqlParameter object and pass it to
the DAL, right? If not, how do we contruct the SqlParameter object?
Please deconfuse. Thanks.

Re: BLL & DAL: How are they different?

"gnewsgroup" wrote in message
news:9e0ab5b7-81d1-493c-a738-c4ee366e6133@k2g2000hse.googleg roups.com...

> Thank you and I understand then that no changes need to be made in the
> DAL after we make changes to the stored procedure, but, it seems that
> the BLL still needs to know about the parameter change in the stored
> procedure in order to construct the SqlParameter object and pass it to
> the DAL, right?

Of course it does!

You've modified your stored procedure because your business requirements
have changed, therefore you need to modify your BLL accordingly.

What *hasn't* changed is the *method* by which the BLL talks to the RDBMS,
i.e. the DAL...


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

Re: BLL & DAL: How are they different?

On Jan 29, 10:11=A0am, "Mark Rae [MVP]" wrote:
> "gnewsgroup" wrote in message
>
> news:9e0ab5b7-81d1-493c-a738-c4ee366e6133@k2g2000hse.googleg roups.com...
>
> > Thank you and I understand then that no changes need to be made in the
> > DAL after we make changes to the stored procedure, but, it seems that
> > the BLL still needs to know about the parameter change in the stored
> > procedure in order to construct the SqlParameter object and pass it to
> > the DAL, right?
>
> Of course it does!
>
> You've modified your stored procedure because your business requirements
> have changed, therefore you need to modify your BLL accordingly.
>
> What *hasn't* changed is the *method* by which the BLL talks to the RDBMS,=

> i.e. the DAL...
>
> --
> Mark Rae
> ASP.NET MVPhttp://www.markrae.net

OK, thanks. I got an idea now.

Re: BLL & DAL: How are they different?

"Mark Rae [MVP]" wrote in message
news:umBhvkoYIHA.4880@TK2MSFTNGP03.phx.gbl...
> "gnewsgroup" wrote in message
> news:9e0ab5b7-81d1-493c-a738-c4ee366e6133@k2g2000hse.googleg roups.com...
>
>> Thank you and I understand then that no changes need to be made in the
>> DAL after we make changes to the stored procedure, but, it seems that
>> the BLL still needs to know about the parameter change in the stored
>> procedure in order to construct the SqlParameter object and pass it to
>> the DAL, right?
>
> Of course it does!
>
> You've modified your stored procedure because your business requirements
> have changed, therefore you need to modify your BLL accordingly.

(I'm sure you are aware of this, Mark, but for the benefit of "gnewsgroup" -
who makes a valid point):

This assumes that each stored proc fulfills only one business requirement.
If multiple business objects utilize the stored proc (or table/view/etc if
you don't use stored procs) then you may well be changing the DB because
*one* business requirement changed, but you will still (presumably) have to
change *all* of the BLL code that uses the stored proc. And how do you find
*all* of those places? What if they exist across multiple applications (web,
WinForms, web services, etc)?

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.

Re: BLL & DAL: How are they different?

On Jan 29, 10:39=A0am, "Scott Roberts" software.com> wrote:
> "Mark Rae [MVP]" wrote in messagenews:umBhvkoYIHA=
..4880@TK2MSFTNGP03.phx.gbl...
>
> > "gnewsgroup" wrote in message
> >news:9e0ab5b7-81d1-493c-a738-c4ee366e6133@k2g2000hse.google groups.com...
>
> >> Thank you and I understand then that no changes need to be made in the
> >> DAL after we make changes to the stored procedure, but, it seems that
> >> the BLL still needs to know about the parameter change in the stored
> >> procedure in order to construct the SqlParameter object and pass it to
> >> the DAL, right?
>
> > Of course it does!
>
> > You've modified your stored procedure because your business requirements=

> > have changed, therefore you need to modify your BLL accordingly.
>
> (I'm sure you are aware of this, Mark, but for the benefit of "gnewsgroup"=
-
> who makes a valid point):
>
> This assumes that each stored proc fulfills only one business requirement.=

> If multiple business objects utilize the stored proc (or table/view/etc if=

> you don't use stored procs) then you may well be changing the DB because
> *one* business requirement changed, but you will still (presumably) have t=
o
> change *all* of the BLL code that uses the stored proc. And how do you fin=
d
> *all* of those places? What if they exist across multiple applications (we=
b,
> WinForms, web services, etc)?
>
> 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.

Re: BLL & DAL: How are they different?

I think "maintenance" is the subject on the table.
And there are different ways to approach this.

...

I don't use the method being discussed.

I'll actually do something a little different.

I create and define all parameters inside the DAL layer.
Aka, if my stored procedure changes, I change the DAL code.

The way I communicate things back to the Biz layer is via my "Layout"
classes, defined in the DAL layer as well.

Again, keep in mind that I deal with IDataReader's mostly, and I populate
custom business objects and collections.

So if I need to add a column, I add a extra "column" to the Layout, and then
adjust the Biz layer code.

One goal I have is to be able to swap out RDBMS if I ever had to. Thus my
code never uses a concrete class like SqlParameter.

I also code up my DAL using the Factory Design Pattern, so that I could
switch out the RDBMS without touching the biz code.

Design goals are a part of this. I'm 99% sure I'll always be with Sql
Server, but I have the option to not use it if necessary.

...

There is another maintainence method...that I kinda describe here:
http://www.sqlservercentral.com/articles/Stored+Procedures/t hezerotonparameterproblem/2283/

(Focus on getting the into into variable or temp tables, and NOT the super
duper WHERE clause)
(Aka, once you have info in variable or temp tables, you can do anything you
want to with it).

You can also see this approach here:
http://groups.google.com/group/microsoft.public.sqlserver.pr ogramming/msg/5491c0640ddf9680

I make the contract for my DAL usually accept a strong DataSet and then use
the ds.GetXml() method to push Xml into TSQL.
This way, when I need a change, I update the (strong) dataset, and never
have to touch the method signatures.

I only need to:
1. add a table and or column(s) to the strong dataset.
2. populate this extra table or extra column where its needed.
3. alter the tsql code to handle the small extra bit of xml.

Now, I like Sql Servers Xml's abilities. But I don't like Oracle's,
although I know it can work. Keep in mind, my last Oracle experience was 3
years ago.

But with this approach I can ship xml into the DAL, and then push the entire
thing into TSQL, or I could loop over the dataset table(s) if I had too.
(Say if my db was Access or something, there you don't have alot of BULK
abilities).


This is all food for thought. I like my approach (obviously), and once I
get people onto it, they see the wisdom in it from a maintenace standpoint.

...

I think the principals are important.....and I still like that MS article I
reference (another post) that gives you a bird's eye view,a nd lets you
choose a strategy.

...

But somewhere if you need a change, you have to change (some) code. If I
change my tsql , then I do most of my changes in the DAL.
But pick your poison for that one.




"Mark Rae [MVP]" wrote in message
news:umBhvkoYIHA.4880@TK2MSFTNGP03.phx.gbl...
> "gnewsgroup" wrote in message
> news:9e0ab5b7-81d1-493c-a738-c4ee366e6133@k2g2000hse.googleg roups.com...
>
>> Thank you and I understand then that no changes need to be made in the
>> DAL after we make changes to the stored procedure, but, it seems that
>> the BLL still needs to know about the parameter change in the stored
>> procedure in order to construct the SqlParameter object and pass it to
>> the DAL, right?
>
> Of course it does!
>
> You've modified your stored procedure because your business requirements
> have changed, therefore you need to modify your BLL accordingly.
>
> What *hasn't* changed is the *method* by which the BLL talks to the RDBMS,
> i.e. the DAL...
>
>
> --
> Mark Rae
> ASP.NET MVP
> http://www.markrae.net

Re: BLL & DAL: How are they different?

>> 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.

Re: BLL & DAL: How are they different?

"sloan" wrote in message
news:OVjCf8oYIHA.4712@TK2MSFTNGP04.phx.gbl...

> I create and define all parameters inside the DAL layer.
> Aka, if my stored procedure changes, I change the DAL code.


Horses for courses, really...

To my way of thinking, what you have there isn't a DAL or, at least, not
*only* a DAL because it has to change per app...

The way I do it means I have one and only one DAL which is currently being
used (completely unmodified) by over a dozen live web apps all of which are
totally different, and at least twice that number of desktop apps...


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

Re: BLL & DAL: How are they different?

I don't have to change my DAL for any specific application.

I only change it if there is a TSQL change.

Obviously, if I break the DAL contract, the (N number of) biz layers will
suffer.

If the TSQL never changes, then the DAL doesn't change. And the (N number
of) biz objects using it will work as expected.

.............

But I build my DAL for total and multiple biz layer reuse.

Since my "rules" are:

DAL objects return:

DataSets (strong usually)
IDataReaders
Scalars
Voids/Nothings

then I'm gonna say my DAL objects are DAL only.

I don't see them getting much slimmer than that.






"Mark Rae [MVP]" wrote in message
news:%23O%23r1FqYIHA.5396@TK2MSFTNGP02.phx.gbl...
> "sloan" wrote in message
> news:OVjCf8oYIHA.4712@TK2MSFTNGP04.phx.gbl...
>
>> I create and define all parameters inside the DAL layer.
>> Aka, if my stored procedure changes, I change the DAL code.
>
>
> Horses for courses, really...
>
> To my way of thinking, what you have there isn't a DAL or, at least, not
> *only* a DAL because it has to change per app...
>
> The way I do it means I have one and only one DAL which is currently being
> used (completely unmodified) by over a dozen live web apps all of which
> are totally different, and at least twice that number of desktop apps...
>
>
> --
> Mark Rae
> ASP.NET MVP
> http://www.markrae.net

Re: BLL & DAL: How are they different?

Mark Rae [MVP] wrote:
>> After all, in your DAL, I assume that you still have to contruct the
>> SqlParameter
>> before you call the stored procedure, right?
>
> No!!! You construct the SqlParameters collection in your BLL and *PASS
> IT* to your DAL... E.g.
[...]
> As I mentioned, the above is just the way I do things... It's not the
> only way, nor am I claiming it's the *right* way...

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

IMO this is contrary to the purpose of abstraction as you are placing Data
Access implementation details inside your BLL. It's great if you only have one
place in your BLL where that data is accessed, and will only ever use one
backend (SQL) for data storage, but what about cases where you need a different
solution to retrieve your data -- say, a webservice?


Chris.

Re: BLL & DAL: How are they different?

"sloan" wrote in message
news:%23tabhUrYIHA.1184@TK2MSFTNGP04.phx.gbl...

> I don't have to change my DAL for any specific application.

Me neither...

> I only change it if there is a TSQL change.

I don't even have to do that...


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

Re: BLL & DAL: How are they different?

"Chris Shepherd" wrote in message
news:OmQUAcrYIHA.4172@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