Passing Business Objects through nTier Web App

[Stuart Hilditch]

Hi all,

I am hoping that someone with some experience developing nTier apps can give
me some advice here.

I am writing an nTier web app that began with a Data Access Layer (DAL),
Business Logic Layer (BLL) and User Interface Layer (UIL).

The problem I found with this was circular referencing...

My objects would be defined in the BLL, so let's say for example that I want
to instantiate a new BLL.Customer object in the UIL, and then run
Customer.AddCus tomer() which would in turn pass the object into the DAL,
let's call this method DAL.AddCustomer (BLL.Customer myCustomer) which would
insert into the DB.

The problem is that the BLL needs to reference the DAL and the DAL needs to
reference the BLL (to receive the custom business object), hence a circular
referencing error. I understand that I could turn this custom object into
some sort of generic object[] or collection and pass it then, or
alternatively pass the method field values one by one (not practical with
10+ values)

What I did was to create a 4th 'vertical' layer which I called the ORL
(Object Reference Layer), the purpose of which is to allow all other layers
to reference the same objects so they can be passed between themselves
without issues. The drawback is that for this to work properly you need to
have the objects themselves defined in the ORL, but the methods defined
statically in the BLL.

My question is this...

Is this good programming?

Obviously it would be ideal to have the object constructor and instance
methods declared in the same class, but I can't seem to get this to work
effectively any other way.

I would appreciate any advice.

- Stu

[Wessel Troost]

> The problem is that the BLL needs to reference the DAL and the DAL needs

to
reference the BLL (to receive the custom business object), hence a
circular
referencing error.

That doesn't sound right. The bottom layer shouldn't reference the top
layer. So the DAL should not reference the BLL.

Just like in networking protocols. TCP is built on top of IP. It would
break the layer separation if IP referenced a TCP property.

My advise would be to examine why the DAL references the BLL and redesign
the DAL to remove the reference.

Greetings,
Wessel

[Stuart Hilditch]

Thanks for your reply Wessel.

The reason the DAL needs to reference the BLL is because it need to know
about the object it's being passed.

For example if I have a Customer object in the BLL and I pass it as a
parameter in DAL.UpdateCusto mer(BLL.Custome r myCustomer), the DAL needs to
know what sort of object a 'Customer' is, and so i need to reference the BLL
layer from the DAL layer.

If i didn't do this, i would not be able to pass 'Customer' as a parameter
between layers, i would instead need to either pass the individual
properties one by one, or use another type of object that the DAL already
knows about (ie. object array)

"Wessel Troost" <no*****@like.t he.sun> wrote in message
news:op.sutprqb kf3yrl7@asbel.. .

The problem is that the BLL needs to reference the DAL and the DAL needs
to
reference the BLL (to receive the custom business object), hence a
circular
referencing error.

That doesn't sound right. The bottom layer shouldn't reference the top
layer. So the DAL should not reference the BLL.

Just like in networking protocols. TCP is built on top of IP. It would
break the layer separation if IP referenced a TCP property.

My advise would be to examine why the DAL references the BLL and redesign
the DAL to remove the reference.

Greetings,
Wessel

[Wessel Troost]

Hi Stuart,

For example if I have a Customer object in the BLL and I pass it as a
parameter in DAL.UpdateCusto mer(BLL.Custome r myCustomer), the DAL needs
to
know what sort of object a 'Customer' is, and so i need to reference the
BLL
layer from the DAL layer.

Well, so why don't you move the definition of Customer from the BLL to the
DAL? That seems like a proper place to put it in any case.

Good luck,
Wessel

[Stuart Hilditch]

Hi Wessel,

Thanks for the input.

I see what your saying, but i would tend to think it needs to stay the the
BLL.

As i understand it, the purpose of the DAL is simply to seperate the
datasource interactions from the actual business logic of the application.
So for example if i decided to move from SQL2000 to MySql in the future i
would only need to update the DAL, not rewrite the entire thing.

Also, if i was to move the Customer object into the DAL, then i would really
need to move all my other business objects since virtually all of them
interact with a datasource in some way, and obviously if i did that then i
wouldn't have a BLL anymore, the DAL & BLL would merge and it would become a
2 tier app.

The 3 Tier architecture seems to be used a lot, I would think that someone
would have come accross this issue before.

- Stu

"Wessel Troost" <no*****@like.t he.sun> wrote in message
news:op.sutsvjt tf3yrl7@asbel.. .

Hi Stuart,

For example if I have a Customer object in the BLL and I pass it as a
parameter in DAL.UpdateCusto mer(BLL.Custome r myCustomer), the DAL needs
to
know what sort of object a 'Customer' is, and so i need to reference the
BLL
layer from the DAL layer.

Well, so why don't you move the definition of Customer from the BLL to the
DAL? That seems like a proper place to put it in any case.

Good luck,
Wessel

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

I have used a different approach, My "DAL" has no knowledge about the BLL ,
all it cares about is interacting with the DB , it receive a SqlCommand from
the BLL and it execute it, and return the values.

It's in the BLL where each object ( as Customer ) create theirs command and
then use the DAL to have them executed.

This work on my situation cause I know this system will ALWAYS use a SQL DB.

If you want to have more independency it gets complex, you could have an
abstract factory to create the DAL that interact with the especific DB
back-end.

alternative you could create abstract classes/interfaces in a separate
prject, then have both the BLL and the DAL reference it, this way you avoid
the circular references.
cheers,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

"Stuart Hilditch" <st************ *@gmail.com> wrote in message
news:Rs******** **********@news-server.bigpond. net.au...

Thanks for your reply Wessel.

The reason the DAL needs to reference the BLL is because it need to know
about the object it's being passed.

For example if I have a Customer object in the BLL and I pass it as a
parameter in DAL.UpdateCusto mer(BLL.Custome r myCustomer), the DAL needs to
know what sort of object a 'Customer' is, and so i need to reference the
BLL layer from the DAL layer.

If i didn't do this, i would not be able to pass 'Customer' as a parameter
between layers, i would instead need to either pass the individual
properties one by one, or use another type of object that the DAL already
knows about (ie. object array)

"Wessel Troost" <no*****@like.t he.sun> wrote in message
news:op.sutprqb kf3yrl7@asbel.. .

The problem is that the BLL needs to reference the DAL and the DAL needs
to
reference the BLL (to receive the custom business object), hence a
circular
referencing error.

That doesn't sound right. The bottom layer shouldn't reference the top
layer. So the DAL should not reference the BLL.

Just like in networking protocols. TCP is built on top of IP. It would
break the layer separation if IP referenced a TCP property.

My advise would be to examine why the DAL references the BLL and redesign
the DAL to remove the reference.

Greetings,
Wessel

[Stuart Hilditch]

Thanks Ignacio,

It's not so much that I think that will ever move from SQL svr, I am really
just trying to enforce a complete seperation of data access and business
logic and I would think that by creating SqlCommands within the BLL you are
getting very close to removing the DAL altogether.

Like i said, I've no real interest in access multiple db's so I think an
abstract factory would be overkill, however the seperate project with
classes that can be referenced by both the DAL and the BLL seems like what i
have already in the form of an ORL (Object Reference Layer).

I'm really just curious to know if this is best practise considering this
scenario? The reason is that by using this technique I can't use instance
methods, so effectively my classes & properties are defined in the ORL and
the methods are defined (statically) in the BLL. It's a bit odd programming
in this way, but it works.

- Stu

"Ignacio Machin ( .NET/ C# MVP )" <ignacio.mach in AT dot.state.fl.us > wrote
in message news:Ov******** ******@TK2MSFTN GP09.phx.gbl...

Hi,

I have used a different approach, My "DAL" has no knowledge about the BLL
, all it cares about is interacting with the DB , it receive a SqlCommand
from the BLL and it execute it, and return the values.

It's in the BLL where each object ( as Customer ) create theirs command
and then use the DAL to have them executed.

This work on my situation cause I know this system will ALWAYS use a SQL
DB.

If you want to have more independency it gets complex, you could have an
abstract factory to create the DAL that interact with the especific DB
back-end.

alternative you could create abstract classes/interfaces in a separate
prject, then have both the BLL and the DAL reference it, this way you
avoid the circular references.
cheers,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

"Stuart Hilditch" <st************ *@gmail.com> wrote in message
news:Rs******** **********@news-server.bigpond. net.au...

Thanks for your reply Wessel.

The reason the DAL needs to reference the BLL is because it need to know
about the object it's being passed.

For example if I have a Customer object in the BLL and I pass it as a
parameter in DAL.UpdateCusto mer(BLL.Custome r myCustomer), the DAL needs
to know what sort of object a 'Customer' is, and so i need to reference
the BLL layer from the DAL layer.

If i didn't do this, i would not be able to pass 'Customer' as a
parameter between layers, i would instead need to either pass the
individual properties one by one, or use another type of object that the
DAL already knows about (ie. object array)

"Wessel Troost" <no*****@like.t he.sun> wrote in message
news:op.sutprqb kf3yrl7@asbel.. .

The problem is that the BLL needs to reference the DAL and the DAL
needs to
reference the BLL (to receive the custom business object), hence a
circular
referencing error.

That doesn't sound right. The bottom layer shouldn't reference the top
layer. So the DAL should not reference the BLL.

Just like in networking protocols. TCP is built on top of IP. It would
break the layer separation if IP referenced a TCP property.

My advise would be to examine why the DAL references the BLL and
redesign the DAL to remove the reference.

Greetings,
Wessel

[Wessel Troost]

Hi Stewart,

Also, if i was to move the Customer object into the DAL, then i would

Well I know two kinds of DAL, handwritten and generated. Generation
enforces the separation of layers rule; you can't generate objects the
database doesn't know about. So I assume you're using a handwritten DAL.

Usually in such a scenario, the Customer class would correspond to a
database tabled called (something like) Customers. The DAL would then
contain a class named Customer, with optional operations like
UpdateCustomer( ) and the like.

However, you say your Customer class resides in the BLL. So I'm curious:
what does your DAL contain?

Greetings,
Wessel

[Steve Walker]

Typically, a data access tier is meant to encapsulate the access to
persistent storage such that there is no implementation-dependent code
within the BLL. It's often little more than a thin wrapper on a set of
stored procedures. It shouldn't really know anything at all about your
domain model classes.

The problem you've got is where to put the mapping code to connect the
domain model classes to the data access logic. One option is a separate
mapping library which knows about the data access layer, knows about the
domain model, and mediates between them.

http://www.martinfowler.com/eaaCatalog/dataMapper.html

A less clean but simpler solution [simpler for small implementations ,
I've found that a mapping-based architecture simplifies large / complex
systems] is to access the DAL directly from within the domain classes.
So, you write a DAL with methods which take simple parameters and return
DataTables and/or DataSets. The code mapping the data to the object is
then encapsulated within the domain model class, which is nice, but
knows a little too much about the underlying storage medium, which is
not nice.

--
Steve Walker

[Stuart Hilditch]

Hi Wessel,

My Customer class used to reside in the BLL, but in order for the DAL to
access the Customer object I needed to move it into another layer which I
call an Object Reference Layer (ORL).

Now that Customer is in the ORL (think of it as a vertical layer rather than
a traditional horizontal layer) I am able to access the object from every
other layer (UIL, BLL, DAL) and I can pass the object between these layers.

This saves me from declaring the same class multiple times. If I was to
declare the Customer class in the DAL, the although I could access the
object from the BLL, I could not access it from the UIL (User Interface
Layer).

However, using this technique, I cannot use instance methods. Therefore all
of my methods are static, and in the BLL my methods are used for enforcing
business rules as well as passing through to the DAL from the UIL eg.

public static bool BLL.InsertCusto mer(ORL.Custome r myCustomer)
{
return DAL.InsertCusto mer(myCustomer) ;
}

In the DAL, all of my methods are static and they perform InsertCustomer,
UpdateCustomer, DeleteCustomer, etc actions, and they are always called from
the BLL, never directly from the UIL.

- Stu

"Wessel Troost" <no*****@like.t he.sun> wrote in message
news:op.sutznku of3yrl7@asbel.. .

Hi Stewart,

Also, if i was to move the Customer object into the DAL, then i would

Well I know two kinds of DAL, handwritten and generated. Generation
enforces the separation of layers rule; you can't generate objects the
database doesn't know about. So I assume you're using a handwritten DAL.

Usually in such a scenario, the Customer class would correspond to a
database tabled called (something like) Customers. The DAL would then
contain a class named Customer, with optional operations like
UpdateCustomer( ) and the like.

However, you say your Customer class resides in the BLL. So I'm curious:
what does your DAL contain?

Greetings,
Wessel