Some architecture advice

[V. Jenks]

I apologize if this is the wrong forum for this, I could
not locate one that was exactly appropriate for this topic.

Over the last couple of years I've been doing a lot of
reading on design patterns and different types of
architectures for building high-performance, scalalble
n-tier apps.

I've used business objects for a while, since moving to C#
and asp.net from classic asp but I'm wondering how I can
make apps that are more maintainable.

When it comes down to it, I'll simply create a struct with
properties and that is usually what constitutes a "business
(model) object". I'll usually use another set of classes
to join a home-baked DAO layer to my business objects,
using a "bridge" pattern.

On the UI layer I'll use a set of classes as a "facade" to
call the bridge-layer (DAO+Biz Objects).

This way, each layer is independent of one another and each
is less "aware" of the other so I'm free to alter them
independently, when needed.

Being relatively inexperienced with architecture I'm sure
I'm doing quite a few things wrong and I'm sure there are
better ways of doing what I'm doing, so hopefully some of
you can comment to that.

1. When using classes to model my data, I find it
complicated when a change happens in the database (new
field, changed data-type, etc.) I have to then alter my
model object and everything that touches it, this is very
time consuming. I've heard a lot of talk about O/R mapping
but I'm really trying to keep performance my first
priority. This process I'm using is especially painful
with stored procuedres...by the way.

2. Also, this model makes it very complicated to use joined
database tables and I often have to call a single table
at-a-time as opposed to joins. This can be good for
performance but can also create a lot of extra code in the
middle-tier - and a lot of round-trips to the DB which
joins would prevent (one-to-one relationships).

3. The objects are not easily persistable - I have to stuff
it in a session variable from page-to-page or make a
round-trip to the DB server to store the data, then go
through the complicated, code-heavy process of calling it
back out and storing it in memory (biz objects) again.

4. From layer-to-layer, I'm writing a lot of redundant code
(bridge layer has function to "GetCollectionX()", facade
repeats this to provide same collection to UI layer, etc.)

These are just a few of the problems I've run into while
experimenting and I'm quite sure some of these questions
are fundamental and are heavily debated.

I'm not proud of it but I spent quite a bit of time (before
asp.net and OOP) building a lot of 2-tier asp apps using a
lot of scripting and spaghetti code. Now I'm trying to
adjust as best as possible to building *real* n-tier apps
the proper way.

I've taken cues from sample applications from all over the
place but everyone seems to do architecture in a
drastically different way and I can't find one clear
(low-level) way of doing it "right" for enterprise-class apps.

Any advice would be much appreciated!

Thanks!

-v

 

[Bijoy Naick]

This may help..
http://msdn.microsoft.com/library/en-us/dnbda/html/bdadotnetarch001.asp

 

[V. Jenks]

Thanks for the link but it doesn't really tell me anything
I don't already know.

This is all very basic, generally-accepted logic but I'm
really looking for details.

I want to see what types of patterns/architecture .NET
programmers are using to create re-usable code for real
business objects.

-v

 

[Bijoy Naick]

check out this article on 4Guys
http://aspnet.4guysfromrolla.com/articles/102302-1.aspx.

It discussed business object implementation..

 

[V. Jenks]

Yeah, I'm already doing this...I'm not after a "how-to" use
business objects, really.

What I do *works* but it just isn't very maintainable. I
have to do quite a bit of work and debugging when adding a
new field to a database table, for example.

Typically I have an object model layer, an example would be
IProduct for a product. IProduct has several properties
that describe a Product (ID, Name, Manufacturer, etc.).

On top of that layer (which in your case, you would use a
web service in the place of an object) - I would have a
"Bridge" (using "bridge" design pattern). This layer
basically provides a bunch of methods for creating,
updating, or deleting data by combining the data-access and
object model layers. So, for example, I would have a
ProductBridge class that provides methods like GetByID(),
GetAll(), Create(), Delete(), etc.

In order to remove the Bridge layer from the UI (web)
layer, I would use a simple Facade class that performs
business logic and makes calls to the Bridge layer. This
approach allows me to keep the UI layer ignorant of what
happens on the back-end and it also, in reverse, keeps the
Bridge layer ignorant of what the UI layer needs, so all of
these layers can operate independently and easily be reused
anywhere.

This approach is nice and neat, cleanly separated, but it
is just *too much work* to make a change to a model
(IProduct)...it ends up reverberating throughout the whole
system and can cause many bugs and unknown issues that take
a long time to iron out.

For example, say I add a field to the Product table in the
database, "quantity". Now I have to change the Product
model object and interface to have a "Quantity" property.
Then I have to edit the Bridge layer (ProductBridge class
in this case) to handle that new property and database
field. Now, to make the UI aware of the new property so I
can display it or send Product Quantity data back to the
database, I have to edit the Facade layer and the
UI....ugh...you can see where I'm going with this...it gets
tedious.

Anyhow, I'd like a more "automatic" approach to
maintenance....haha! No seriously, I'd like to make this a
little more simple, that's all.

 

[bruce barker]

it sounds like none of your layers are doing any abstraction of the data, so
a change in one, is a change in all. your components are too tightly
coupled. why does the Facade need details about product?

the Facade should be about data input, validation, and cross edits, and
navigation commands. the datums could be named e1-e20. you need to design a
structure to pass data element to Facade, that gives the Facade the info it
needs (data validation rules, max length, captions, requirements, etc.)

-- bruce (sqlwork.com)





| Yeah, I'm already doing this...I'm not after a "how-to" use
| business objects, really.
|
| What I do *works* but it just isn't very maintainable. I
| have to do quite a bit of work and debugging when adding a
| new field to a database table, for example.
|
| Typically I have an object model layer, an example would be
| IProduct for a product. IProduct has several properties
| that describe a Product (ID, Name, Manufacturer, etc.).
|
| On top of that layer (which in your case, you would use a
| web service in the place of an object) - I would have a
| "Bridge" (using "bridge" design pattern). This layer
| basically provides a bunch of methods for creating,
| updating, or deleting data by combining the data-access and
| object model layers. So, for example, I would have a
| ProductBridge class that provides methods like GetByID(),
| GetAll(), Create(), Delete(), etc.
|
| In order to remove the Bridge layer from the UI (web)
| layer, I would use a simple Facade class that performs
| business logic and makes calls to the Bridge layer. This
| approach allows me to keep the UI layer ignorant of what
| happens on the back-end and it also, in reverse, keeps the
| Bridge layer ignorant of what the UI layer needs, so all of
| these layers can operate independently and easily be reused
| anywhere.
|
| This approach is nice and neat, cleanly separated, but it
| is just *too much work* to make a change to a model
| (IProduct)...it ends up reverberating throughout the whole
| system and can cause many bugs and unknown issues that take
| a long time to iron out.
|
| For example, say I add a field to the Product table in the
| database, "quantity". Now I have to change the Product
| model object and interface to have a "Quantity" property.
| Then I have to edit the Bridge layer (ProductBridge class
| in this case) to handle that new property and database
| field. Now, to make the UI aware of the new property so I
| can display it or send Product Quantity data back to the
| database, I have to edit the Facade layer and the
| UI....ugh...you can see where I'm going with this...it gets
| tedious.
|
| Anyhow, I'd like a more "automatic" approach to
| maintenance....haha! No seriously, I'd like to make this a
| little more simple, that's all.
|
| >-----Original Message-----
| >check out this article on 4Guys
| >http://aspnet.4guysfromrolla.com/articles/102302-1.aspx.
| >
| >It discussed business object implementation..
| >
| message
| >| >> Thanks for the link but it doesn't really tell me anything
| >> I don't already know.
| >>
| >> This is all very basic, generally-accepted logic but I'm
| >> really looking for details.
| >>
| >> I want to see what types of patterns/architecture .NET
| >> programmers are using to create re-usable code for real
| >> business objects.
| >>
| >> -v
| >>
| >>
| >> >-----Original Message-----
| >> >This may help..
| >>
| >http://msdn.microsoft.com/library/en-us/dnbda/html/bdadotnetarch001.asp
| >> >
| >> message
| >> >| >> >> I apologize if this is the wrong forum for this, I could
| >> >> not locate one that was exactly appropriate for this
| topic.
| >> >>
| >> >> Over the last couple of years I've been doing a lot of
| >> >> reading on design patterns and different types of
| >> >> architectures for building high-performance, scalalble
| >> >> n-tier apps.
| >> >>
| >> >> I've used business objects for a while, since moving
| to C#
| >> >> and asp.net from classic asp but I'm wondering how I can
| >> >> make apps that are more maintainable.
| >> >>
| >> >> When it comes down to it, I'll simply create a struct
| with
| >> >> properties and that is usually what constitutes a
| "business
| >> >> (model) object". I'll usually use another set of classes
| >> >> to join a home-baked DAO layer to my business objects,
| >> >> using a "bridge" pattern.
| >> >>
| >> >> On the UI layer I'll use a set of classes as a
| "facade" to
| >> >> call the bridge-layer (DAO+Biz Objects).
| >> >>
| >> >> This way, each layer is independent of one another
| and each
| >> >> is less "aware" of the other so I'm free to alter them
| >> >> independently, when needed.
| >> >>
| >> >> Being relatively inexperienced with architecture I'm sure
| >> >> I'm doing quite a few things wrong and I'm sure there are
| >> >> better ways of doing what I'm doing, so hopefully some of
| >> >> you can comment to that.
| >> >>
| >> >> 1. When using classes to model my data, I find it
| >> >> complicated when a change happens in the database (new
| >> >> field, changed data-type, etc.) I have to then alter my
| >> >> model object and everything that touches it, this is very
| >> >> time consuming. I've heard a lot of talk about O/R
| mapping
| >> >> but I'm really trying to keep performance my first
| >> >> priority. This process I'm using is especially painful
| >> >> with stored procuedres...by the way.
| >> >>
| >> >> 2. Also, this model makes it very complicated to use
| joined
| >> >> database tables and I often have to call a single table
| >> >> at-a-time as opposed to joins. This can be good for
| >> >> performance but can also create a lot of extra code
| in the
| >> >> middle-tier - and a lot of round-trips to the DB which
| >> >> joins would prevent (one-to-one relationships).
| >> >>
| >> >> 3. The objects are not easily persistable - I have to
| stuff
| >> >> it in a session variable from page-to-page or make a
| >> >> round-trip to the DB server to store the data, then go
| >> >> through the complicated, code-heavy process of calling it
| >> >> back out and storing it in memory (biz objects) again.
| >> >>
| >> >> 4. From layer-to-layer, I'm writing a lot of
| redundant code
| >> >> (bridge layer has function to "GetCollectionX()", facade
| >> >> repeats this to provide same collection to UI layer,
| etc.)
| >> >>
| >> >> These are just a few of the problems I've run into while
| >> >> experimenting and I'm quite sure some of these questions
| >> >> are fundamental and are heavily debated.
| >> >>
| >> >> I'm not proud of it but I spent quite a bit of time
| (before
| >> >> asp.net and OOP) building a lot of 2-tier asp apps
| using a
| >> >> lot of scripting and spaghetti code. Now I'm trying to
| >> >> adjust as best as possible to building *real* n-tier apps
| >> >> the proper way.
| >> >>
| >> >> I've taken cues from sample applications from all
| over the
| >> >> place but everyone seems to do architecture in a
| >> >> drastically different way and I can't find one clear
| >> >> (low-level) way of doing it "right" for enterprise-class
| >> apps.
| >> >>
| >> >> Any advice would be much appreciated!
| >> >>
| >> >> Thanks!
| >> >>
| >> >> -v
| >> >
| >> >
| >> >.
| >> >
| >
| >
| >.
| >

 

[V. Jenks]

Well, I'm not doing any real validation, per-se, in the
Facade, that is being done on the client in the one
application that is using this code. I suppose I could but
that's another story for another time.

The facade layer in this case is doing what a facade does,
providing a simplified interface to the UI layer so the UI
doesn't need to know what is being done behind-the-scenes
within the facade. The UI will always be provided a
particular set of functionality regardless of how the
facade implements it...so changes can be done in the facade
w/o changing the UI.

It has to be aware of my model objects otherwise it would
not be able to pass them (or collections of them) from the
bridge layer, and vice-versa.

No, it actually isn't abstracted enough as far as
data-types go, that's sort of what I'm looking for
(examples would be great!)

What you're talking about, I think, would be an entirely
different "facade" and a separate piece of functionality
altogether.

Thanks!

-v