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

[Michael Rodriguez]

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

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

Why would you think there would be a massive performance hit? Where do you
think that would occur? I know datasets can be slow if they are loaded with
thousands of records, but I'm designing my app to avoid scenarious like
that.

I chose to use datasets for several reasons:

1.) They pass easily through web services. You can pass custom types,
but it requires manually changing the reference.cs file each time.
2.) They have built-in support for remembering which rows get added,
edited, deleted, etc. This is especially true in a data grid. If you pass
your data object to a data grid, how do you know which rows got updated?
3.) They allow for very easy data binding on Windows forms.
4.) You can give custom sql scripts to a data adapter, then let it do all
of the data manipulation work for you. There is no need to loop through
each record manually and figure out whether it needs to be added, deleted,
etc.
5.) You can use DataSet1.GetCha nges() to only pass only the changes to
your web service and then to your data layer.
...

Thanks,

Mike

[Stuart Hilditch]

Hi Mike,

I would tend to think they were better in cases where you use thousands of
records.

I agree they are very handy, but there is a very instantiation & marshalling
cost that is incurred everytime you create a new object.

From
http://msdn.microsoft.com/library/de...tml/BOAGag.asp

"High instantiation and marshalling costs. DataSets result in the creation
of several subobjects (DataTable, DataRow, and DataColumn), which means that
DataSets can take longer to instantiate and marshal than XML strings or
custom entity components. The relative performance of DataSets improves as
the amount of data increases, because the overhead of creating the internal
structure of the DataSet is less significant than the time it takes to
populate the DataSet with data."

I would not use them for individual objects, but for large sets of data they
are great.

When retreiving data from a datastore, a datareader is the way to go if
performance is a consideration. Check out this benchmark ...

http://www.devx.com/vb2themax/Articl...7/1954?pf=true

- Stu

"Michael Rodriguez" <mi**@nospamfor me.com> wrote in message
news:%2******** ********@TK2MSF TNGP10.phx.gbl. ..

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

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

Why would you think there would be a massive performance hit? Where do
you think that would occur? I know datasets can be slow if they are
loaded with thousands of records, but I'm designing my app to avoid
scenarious like that.

I chose to use datasets for several reasons:

1.) They pass easily through web services. You can pass custom types,
but it requires manually changing the reference.cs file each time.
2.) They have built-in support for remembering which rows get added,
edited, deleted, etc. This is especially true in a data grid. If you
pass your data object to a data grid, how do you know which rows got
updated?
3.) They allow for very easy data binding on Windows forms.
4.) You can give custom sql scripts to a data adapter, then let it do
all of the data manipulation work for you. There is no need to loop
through each record manually and figure out whether it needs to be added,
deleted, etc.
5.) You can use DataSet1.GetCha nges() to only pass only the changes to
your web service and then to your data layer.
...

Thanks,

Mike

[Michael Rodriguez]

Hi Stu,

I've read those benchmarks and it did give me some concern. However,
there's something I still don't understand about using custom entities to
store your data. If you bind a grid to your business object, how do you
know which rows get changed? How do you know which rows need to be added
and/or deleted?

Also, do you have to pass your business objects through a web service (I
do)? Web services aren't great for passing custom types like that...

Thanks,

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

Hi Mike,

I would tend to think they were better in cases where you use thousands of
records.

I agree they are very handy, but there is a very instantiation &
marshalling cost that is incurred everytime you create a new object.

From
http://msdn.microsoft.com/library/de...tml/BOAGag.asp

"High instantiation and marshalling costs. DataSets result in the creation
of several subobjects (DataTable, DataRow, and DataColumn), which means
that DataSets can take longer to instantiate and marshal than XML strings
or custom entity components. The relative performance of DataSets improves
as the amount of data increases, because the overhead of creating the
internal structure of the DataSet is less significant than the time it
takes to populate the DataSet with data."

I would not use them for individual objects, but for large sets of data
they are great.

When retreiving data from a datastore, a datareader is the way to go if
performance is a consideration. Check out this benchmark ...

http://www.devx.com/vb2themax/Articl...7/1954?pf=true

- Stu

[John B]

Michael Rodriguez wrote:

Hi Stu,

I've read those benchmarks and it did give me some concern. However,
there's something I still don't understand about using custom entities to
store your data. If you bind a grid to your business object, how do you
know which rows get changed? How do you know which rows need to be added
and/or deleted?
All that should be catered for in IBindingList.
I havent actually implemented deletion, but have done add's.
Also, do you have to pass your business objects through a web service (I
do)? Web services aren't great for passing custom types like that...

Im not sure

<snip)

JB

[Stuart Hilditch]

Hi Mike,

I think it really depends on the context of the problem. Generally I use a
mix of business objects and datasets, I find that custom entities give me a
lot more control, you can use them as a collection and there are a number of
interfaces that will allow you more control over binding, etc.

I also use datasets when a large quantity of data is moving from my Data
Access Layer to my User Interface Layer relatively unchanged, but I would
usually implement caching in that case. Unfortunately I have not had any
experience with web services, but you can easily serialize business objects
so I imagine it can be done.

Hope this helps.

- Stu

"Michael Rodriguez" <mi**@nospamfor me.com> wrote in message
news:eo******** ******@TK2MSFTN GP15.phx.gbl...

Hi Stu,

I've read those benchmarks and it did give me some concern. However,
there's something I still don't understand about using custom entities to
store your data. If you bind a grid to your business object, how do you
know which rows get changed? How do you know which rows need to be added
and/or deleted?

Also, do you have to pass your business objects through a web service (I
do)? Web services aren't great for passing custom types like that...

Thanks,

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

Hi Mike,

I would tend to think they were better in cases where you use thousands
of records.

I agree they are very handy, but there is a very instantiation &
marshalling cost that is incurred everytime you create a new object.

From
http://msdn.microsoft.com/library/de...tml/BOAGag.asp

"High instantiation and marshalling costs. DataSets result in the
creation of several subobjects (DataTable, DataRow, and DataColumn),
which means that DataSets can take longer to instantiate and marshal than
XML strings or custom entity components. The relative performance of
DataSets improves as the amount of data increases, because the overhead
of creating the internal structure of the DataSet is less significant
than the time it takes to populate the DataSet with data."

I would not use them for individual objects, but for large sets of data
they are great.

When retreiving data from a datastore, a datareader is the way to go if
performance is a consideration. Check out this benchmark ...

http://www.devx.com/vb2themax/Articl...7/1954?pf=true

- Stu

[Michael Rodriguez]

Stu,

It's true that business objects can be serialized and passed through a web
service. The problem is the default proxy class does not know about your
custom type. This means every time you update your web reference, you have
to go into the Reference.cs file and add a reference to your custom type.
The was definitely the case for .NET 1.1. I haven't verified yet whether or
not that has changed for 2.0.

Mike

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

Hi Mike,

I think it really depends on the context of the problem. Generally I use a
mix of business objects and datasets, I find that custom entities give me
a lot more control, you can use them as a collection and there are a
number of interfaces that will allow you more control over binding, etc.

I also use datasets when a large quantity of data is moving from my Data
Access Layer to my User Interface Layer relatively unchanged, but I would
usually implement caching in that case. Unfortunately I have not had any
experience with web services, but you can easily serialize business
objects so I imagine it can be done.

Hope this helps.

- Stu