BLL and DAL.

[Roy]

Recently I've been trying to convert over my sqldatasource's to
objectdatasource's to take advantage of the custom paging functionality
of objectdatasource's. These attempts have plunged me knee-deep into
unfamiliar territory and I'm starting to feel like a rank newbie. What
makes it worse is that---despite my best efforts---I'm struggling to
get anywhere. There's just a lot of theory here I don't understand.

1.) I understand (I think) the core concepts of Business Logic Layers
and Data Access Layers. They are a middle tier between the web front
end and the database back end. But how are they different? They sound
like different names for the same thing.

2.) The examples I've found online of BLL's and DAL's show some
connection strings written in VB or C#. Ok. So BLL's and DAL's are just
functions written in VB or C# that connect to a database. How is this
any different from simply writing the same code in the page's
codebehind? What's the point of creating yet another VB file?

3.) Why are they stored in the app_code directory? Is this just simple
organization or is there some compiling thing going on here that I
don't get?

4.) This may be answered by question 2, but what's the advantage of
creating a BLL/DAL? It must be a pretty big advantage since they figure
so prominently in the world of the objectdatasource, but to my eyes it
just looks like something that would slow down the whole web experience
for a user.

As you can see, I'm quite confused. Can someone shed some light for me?
Thanks much!

 

[Guest]

Hey son,
I'll give it a shot! First off... most application(s) in the commerce world
are developed by teams. One group or person responsible for frontends, one
for the DAL,BLL and last, but not least, one for the datasource. You have
others like the archietects, system designers etc. So the complexity is
divided into layers and can be built individually/separately.

That way the application(s) are built into components. Recently there has
been the hype, more than ever before, because of certain patterns like
Factory and many others.

Archietects have found that processing power is in abaundance same for
memeory, so they can break the application up into very small objects. This
will make the code more easily readable. Now with the C# AND vb.net they are
going crazy.

Now the DAL is a layer where all data access is done. All the codes and
components to access data is found in this layer. That way this layer is now
reusable in other projects and totally separate.

BLL is where all logic is handled before the object is passed to the DAL.
Example. Let's say customer max credit limit (business rule or company
policy) is 1000000.00 then you set this in the BLL. That way the BLL checks
the customer object ( eg customer.CreditLimit < 1000000.00) If he is <
1000000.00 hen it's passed to DAL.

You save a trip to datastore and network traffic.

Hope that helps.

 

[Guest]

I meant ...You save a trip to datastore and network traffic if his limit is >
than 1000000.00.

 

[Roy]

Thanks for the response Chris.

So generally speaking, BLL/DAL's are designed for division of labor and
teamwork. Not necessarily speed and efficiency. True?

Your description below of a BLL (credit limit, etc...) seems like a
VB/C# solution to what has typically been handled by javascript.
Basically, validating data before any postback occurs. True?

To dig a little deeper:
1.) Objectdatasource's essentially force you into using a DAL.
2.) Not only that, to implement custom paging requires TWO trips to the
database (one to get the count of total records and the other to
actually get the page of records needed).
Both of these things seem totally inefficient. Is this just bad design

 

[Guest]

Hi,
It's not only for division of labor you do get the speed and efficiency
because the codes are processed in chunks. I can get a bit more detailed but
you'll probably get confused. You see, objects are prepared and return faster.

BLL has not replaced javascript. It's the layer that handled business logic.
Another example...in an ecommerce app you can use an order object to collect
the order from a cart object and process the payment.

Check this out for ObjectDatasource
http://www.c-sharpcorner.com/Code/2004/Oct/ObjectDataSource.asp

There they have

using System;

/// <summary>
/// Summary description for Content
/// </summary>
public class AuthorData
{
// Private variables
private string name = null;
private int age = 0;
private bool consultant = false;

public AuthorData()
{
}

public string Name
{
get { return name; }
set { name = value; }
}

public int Age
{
get { return age; }
set { age = value; }
}

public bool Consultant
{
get { return consultant; }
set { consultant = value; }
}

}

as an AuthorData object. They then fill the object with

using System;

/// <summary>
/// Summary description for Content
/// </summary>
public class AuthorDatausing System;
using System.Collections;

public class BusinessHelper
{
public BusinessHelper()
{
}

public ICollection GetData()
{
ArrayList list = new ArrayList();
AuthorData row = new AuthorData();
row.Name = "Mahesh Chand";
row.Age = 29;
row.Consultant = true;
list.Add(row);

row = new AuthorData();
row.Name = "Jack Black";
row.Age = 2;
row.Consultant = false;
list.Add(row);

return list;
}
}

and return the object. The object now has data so you get ObjectDatasource.
They then bind the object to a grid.

Hope that helps.

 

[David Hogue]

Thanks for the response Chris.

So generally speaking, BLL/DAL's are designed for division of labor and
teamwork. Not necessarily speed and efficiency. True?

They can be used for devision of labor. More often than not I see them
used to make reusable components and organize code.

It's often useful to separate the business logic from the user interface
and the database. If the business rules are kept separate then you can
do things like rearrange the UI, or change the database without
affecting the business logic. Alternatively if you want to change a
business rule, there is only one place that code lives.

To take Chris' example: what if there were 3 different pages where you
wanted to change the max credit limit? You would have to open each page
and make the change. In this case you might be able to include a common
file or put the max credit in the config, but it isn't always that simple.

Your description below of a BLL (credit limit, etc...) seems like a
VB/C# solution to what has typically been handled by javascript.
Basically, validating data before any postback occurs. True?

Validation should always be done on the server. What if the user has
JavaScript disabled (or disables it to get around your limits)? You
can, however, add JavaScript validation to make the UI friendlier. The
built in validators do both server and client side validation.

To dig a little deeper:
1.) Objectdatasource's essentially force you into using a DAL.
2.) Not only that, to implement custom paging requires TWO trips to the
database (one to get the count of total records and the other to
actually get the page of records needed).
Both of these things seem totally inefficient. Is this just bad design
on the asp.net dev team's part or am I just not getting the deeper
logic?

1.) I haven't used ObjectDataSource yet, but I was under the impression
that you would use it if you already had a DAL that you wanted to make
use of. You might look into SqlDataSource if you don't want to create a DAL

2.) I think for paging (with or without datasources and DALs) you would
use 2 queries: one to get the size and one to get the page's contents.
The size could be cached if the data isn't likely to change too quickly.
The other option is get all the data and count the rows returned, and
that wouldn't be any better. In reality the two queries should be
pretty lightweight.

The ObjectDataSource might not be appropriate for all apps. If you do
little processing and just display the raw data in tables this could be
overkill. I know there is at least a SqlDataSource and there might be
more datasources.


Wow, that's quite a bit of text. Sorry if I started rambling...

 

[Manu]

Roy,

if you can get the total row count in the same query thas retrieves the
current page you can do custom paging with only one trip to the
database.

Take a look at this:

http://www.manuelabadia.com/blog/PermaLink,guid,f002752d-1258-475d-9ec0-eee3bd98d0a4.aspx

Hope it helps,
Manuel Abadia
http://www.manuelabadia.com

Roy ha escrito:

 

[sloan]

http://sholliday.spaces.msn.com/

My June 2006 provide a basic 1.1 and 2.0 architecture.

2005 is built around "Rapid Development". Rapid is not always the same (or
seldom is the same) as "Good Tiered Development".

That's my quick take on it.

 

[sloan]

Sorry

its the June entry
and the 5/24/2006
entry.

 

[V]

Hello Roy,

As others have mentioned, the merits of dividing up your application in
layers are many. And yes it can be confusing to begin with, but pays
off nicely later.

If you are only beginning to transform you application into a
structured one with objects at the UI level rather than Datasets, then
you may wish to read up a little more.

I recommed a framework called CSLA.Net 2.0.

Google for it or go to (www.lhotka.net).

Regards,
Vaibhav

 

[Guest]

Nice resource. Rockford Lhotka is good!

Hello Roy,

As others have mentioned, the merits of dividing up your application in
layers are many. And yes it can be confusing to begin with, but pays
off nicely later.

If you are only beginning to transform you application into a
structured one with objects at the UI level rather than Datasets, then
you may wish to read up a little more.

I recommed a framework called CSLA.Net 2.0.

Google for it or go to (www.lhotka.net).

Regards,
Vaibhav