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.AddCustomer() 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.UpdateCustomer(BLL.Customer 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]

Hi Stuart,

For example if I have a Customer object in the BLL and I pass it as a
parameter in DAL.UpdateCustomer(BLL.Customer 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

 

[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,

 

[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

 

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

 

[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.InsertCustomer(ORL.Customer myCustomer)
{
return DAL.InsertCustomer(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

 

[Stuart Hilditch]

Hi Steve,

Thanks for the response.

I think your suggestion of writing the DAL as 'stored procedure' wrappers
that accept a simple input, and return a dataset, or datatable is pretty
much what i have aimed to do.

The important thing for me is to be able to pass the actual business object
as a single parameter through to the DAL, and i have achieved this by
creating an Object Reference Layer.

At this point i think i have what i want, the DAL knows nothing about the
BLL but knows where the ORL is, if it's passed a Customer object.

 

[Wessel Troost]

Hi Stuart,

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

One disadvantage of this approach is the need for static methods, as you
explain yourself. But what is the advantage of this approach?

You reasoned earlier that you wanted the Customer object outside of the
DAL, because otherwise you'd "need to move all my other business
objects". But, by introducing another layer, you have moved the objects
outside of the BLL already.

So, why not integrate the ORL into the DAL, and call it DAL afterwards?

It's not very important anyway-- the important thing is like you say:

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.

That sounds good, the BLL and DAL are doing their work! Wether you move
part of what is normally in the DAL outside it, is far less important,
IMHO.

Greetings,
Wessel

 

[Nigel Norris]

Stuart,

Have you read Microsoft's writings on this topic?

"Designing Data Tier Components and Passing Data Through Tiers"

See:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/boagag.asp

It may leave you more confused, mind you, because it's not entirely clear in
answering your question.

 

[Michael Rodriguez]

Hi Stuart,

Personally, I use strongly-typed datasets as my business objects. I have a
project that only contains the strongly-typed datasets, and both the BLL
project and the DAL project can then reference the datasets project. The
UIL project also references the strongly-typed datasets project, which makes
for easy data binding.

HTH,

Mike Rodriguez

 

[Stuart Hilditch]

I haven't come across this article yet.

Thanks very much Nigel.

Stuart,

Have you read Microsoft's writings on this topic?

"Designing Data Tier Components and Passing Data Through Tiers"

See:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/boagag.asp

It may leave you more confused, mind you, because it's not entirely clear
in answering your question.

-------
Nigel Norris

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

 

[Stuart Hilditch]

Hi Michael,

Sounds like your doing the same thing I am only using datasets rather than
business objects. I would have thought that your application would take a
massive performance by using datasets in this way, especially if you use a
lot of objects. I suppose you can help with caching (if it's an option).

- Stu

Hi Stuart,

Personally, I use strongly-typed datasets as my business objects. I have
a project that only contains the strongly-typed datasets, and both the BLL
project and the DAL project can then reference the datasets project. The
UIL project also references the strongly-typed datasets project, which
makes for easy data binding.

HTH,

Mike Rodriguez

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

 

[laimis]

Hey,

Just talking from experience, I have achieved the seperation of business
objects (BLL) from database specific calls (DAL) by having mappers that
some of the people talked about.

You can read my comments about the design of my blog which currently can
run on MySql and Sql Server by going here:
http://www.laimisnet.com/default.aspx?entryid=18
.. Anyways, the design fit my needs, and I can add another storage
mechanism without modifying bll.

 

[Stuart Hilditch]

Very interesting reading Laimis.

I am curious, is the mapper implemented as a seperate project in the
solution?

Obviously this is a very good solution for anyone wanting a great deal of
flexibility in which data store is used.

 

[John B]

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

Google Dependency Inversion Principle and Interface Segregation Principle.

I am by no means an expert but..
In the past I have created another assembly containing an interface that
both the DAL and BLL know about.
This interface pretty much only contains properties for all the db table
columns.
Thus, the DAL classes know about the interface and can interact with
that and the BLL classes implement this interface.

HTH
JB

 

[Stuart Hilditch]

I did originally use interfaces in the DAL, but it resulted in so much messy
code (some of my object have 25+ properties) I decided that it was far
cleaner to simply reference the object from the ORL.

- Stu

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

Google Dependency Inversion Principle and Interface Segregation Principle.

I am by no means an expert but..
In the past I have created another assembly containing an interface that
both the DAL and BLL know about.
This interface pretty much only contains properties for all the db table
columns.
Thus, the DAL classes know about the interface and can interact with that
and the BLL classes implement this interface.

HTH
JB