V
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
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