Layer design - some difficulties..

[Rob Meade]

Hi all,

My web app is using a layered design, whereby I have UI/BOL/DAL layers....

So far things have been running fine and as the first app using this
approach I've seen some real benefits...

The problem I ran into yesterday had me in circles, and driving me crazy...

I have a following objects, class variables, properties and methods have
been "trimmed" for the posting....

RoleResourceCollection
-can contain many RoleResource objects

RoleResource object
-contains Resource object

ResourceObject
-contains AccessLevelCollection

AccessLevelCollection
-can contain many AccessLevel objects

AccessLevel object
-contains ResourceParameterCollection

ResourceParameterCollection
-can contain many ResourceParameter objects
Now, with other objects that I've created, I use my SQL.vb class which
contains various private/public methods to extract the data from our sql
server and return it, typically as a datatable, sometimes a dataset, but
never as an explicit object of types that I've created, for example, I
wouldn't return a "User" object from my sql.vb data access layer, as I feel
that this is incorrect, instead I should return the data to the calling
function which would then populate my object...perhaps like this:

So, with regards to the above object, how the hell do I get all my data!

Whilst I could produce a stored procedure to call that would return my
RoleResources's to populate the collection, and all of the Resources,
AccessLevels, ResourceParameters etc, its going to return a MASSIVE quantity
of rows, that, couple with the fact that I would then need to write a shed
load of code that iterates through the massive collection of datarows and
keeps checking to see if it should now be creating a new ResourceParameter,
or a new AccessLevel or whatever, ie, a lot of parsing of the data...it
seems a bit overkill and doesn't feel right...

I could obviously have a method thats called from each of the objects being
instantiated so that they run off to sql and just return the data needed to
create the object, downside here is that this would means LOTS of calls (a
parameter collection for example might contains 200+ datarows that need to
be turned into ResourceParameter objects, that would be 200+ database
connections!)...

I could however have a method in my sql.vb data access layer which creates
one connection, and then calls a series of stored procedures passing in the
connection, thus not having lots and lots of connections, this is great, but
my problem now is that it now doesn't seem easy/practical to just return
datatables, ie, if I'm iterating through and I return the data for a
ResourceParameter, really I need to create it then and and there, the same
is true of the other objects, but then this feels wrong because now I'm
creating my own explicit objects in the DAL which I've been trying to avoid
doing?!

Can anyone give me some pointers/suggestions on this please - am I missing
something, have I interpretted stuff wrong, is what I'm doing right? I have
found a lot recently that using this new approach (new for me), has had some
excellent benefits, but more often than not I can spend nearly a week on one
very small problem, which, if I think back to my ASP days I'd probably have
(badly) just returned a record set and iterated through it on the page! :o)

To clarify on my insane ramblings, I guess I'm asking, should I only be
returning data from the DAL (as its name would suggest) and not explicit
objects (ie, my own objects), and what would be the best approach on the
collections hell in the example above...

Any help is appreciated....

Rob

[sloan]

What you're talking about is the Layer's "Glue".

And a reference to read from start to finish, aka, very informative for a
bird's eye view:
http://msdn2.microsoft.com/en-us/library/ms978496.aspx

Read this section
"Deploying Business Entities"
several times. Read it carefully.
MS recommends putting "glue" components in a seperate/common assembly.
Here is how I do it. Which is one implementation of the above URL.
http://sholliday.spaces.live.com/blog/
5/24/2006
Custom Objects/Collections and Tiered Development

Here, my glue is Data.DataSets assembly.

"Rob Meade" <ku***************@edaem.borwrote in message
news:uA*************@TK2MSFTNGP03.phx.gbl...

Hi all,

My web app is using a layered design, whereby I have UI/BOL/DAL layers....

So far things have been running fine and as the first app using this
approach I've seen some real benefits...

The problem I ran into yesterday had me in circles, and driving me

crazy...

>
I have a following objects, class variables, properties and methods have
been "trimmed" for the posting....

RoleResourceCollection
-can contain many RoleResource objects

RoleResource object
-contains Resource object

ResourceObject
-contains AccessLevelCollection

AccessLevelCollection
-can contain many AccessLevel objects

AccessLevel object
-contains ResourceParameterCollection

ResourceParameterCollection
-can contain many ResourceParameter objects
Now, with other objects that I've created, I use my SQL.vb class which
contains various private/public methods to extract the data from our sql
server and return it, typically as a datatable, sometimes a dataset, but
never as an explicit object of types that I've created, for example, I
wouldn't return a "User" object from my sql.vb data access layer, as I

feel

that this is incorrect, instead I should return the data to the calling
function which would then populate my object...perhaps like this:

So, with regards to the above object, how the hell do I get all my data!

Whilst I could produce a stored procedure to call that would return my
RoleResources's to populate the collection, and all of the Resources,
AccessLevels, ResourceParameters etc, its going to return a MASSIVE

quantity

of rows, that, couple with the fact that I would then need to write a shed
load of code that iterates through the massive collection of datarows and
keeps checking to see if it should now be creating a new

ResourceParameter,

or a new AccessLevel or whatever, ie, a lot of parsing of the data...it
seems a bit overkill and doesn't feel right...

I could obviously have a method thats called from each of the objects

being

instantiated so that they run off to sql and just return the data needed

to

create the object, downside here is that this would means LOTS of calls (a
parameter collection for example might contains 200+ datarows that need to
be turned into ResourceParameter objects, that would be 200+ database
connections!)...

I could however have a method in my sql.vb data access layer which creates
one connection, and then calls a series of stored procedures passing in

the

connection, thus not having lots and lots of connections, this is great,

but

my problem now is that it now doesn't seem easy/practical to just return
datatables, ie, if I'm iterating through and I return the data for a
ResourceParameter, really I need to create it then and and there, the same
is true of the other objects, but then this feels wrong because now I'm
creating my own explicit objects in the DAL which I've been trying to

avoid

doing?!

Can anyone give me some pointers/suggestions on this please - am I missing
something, have I interpretted stuff wrong, is what I'm doing right? I

have

found a lot recently that using this new approach (new for me), has had

some

excellent benefits, but more often than not I can spend nearly a week on

one

very small problem, which, if I think back to my ASP days I'd probably

have

(badly) just returned a record set and iterated through it on the page!

:o)

>
To clarify on my insane ramblings, I guess I'm asking, should I only be
returning data from the DAL (as its name would suggest) and not explicit
objects (ie, my own objects), and what would be the best approach on the
collections hell in the example above...

Any help is appreciated....

Rob