473,326 Members | 2,438 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,326 software developers and data experts.

Some architecture advice

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
Nov 19 '05 #1
6 1377
This may help..
http://msdn.microsoft.com/library/en...netarch001.asp

"V. Jenks" <an*******@discussions.microsoft.com> wrote in message
news:14****************************@phx.gbl...
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

Nov 19 '05 #2
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...netarch001.asp

"V. Jenks" <an*******@discussions.microsoft.com> wrote in messagenews:14****************************@phx.gbl...
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

.

Nov 19 '05 #3
check out this article on 4Guys
http://aspnet.4guysfromrolla.com/articles/102302-1.aspx.

It discussed business object implementation..

"V. Jenks" <an*******@discussions.microsoft.com> wrote in message
news:04****************************@phx.gbl...
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...netarch001.asp

"V. Jenks" <an*******@discussions.microsoft.com> wrote in

message
news:14****************************@phx.gbl...
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

.

Nov 19 '05 #4
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..

"V. Jenks" <an*******@discussions.microsoft.com> wrote in messagenews:04****************************@phx.gbl...
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...netarch001.asp
>
>"V. Jenks" <an*******@discussions.microsoft.com> wrote in

message
>news:14****************************@phx.gbl...
>> 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
>
>
>.
>

.

Nov 19 '05 #5
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)

"V. Jenks" <an*******@discussions.microsoft.com> wrote in message
news:1a****************************@phx.gbl...
| 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..
| >
| >"V. Jenks" <an*******@discussions.microsoft.com> wrote in
| message
| >news:04****************************@phx.gbl...
| >> 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...netarch001.asp
| >> >
| >> >"V. Jenks" <an*******@discussions.microsoft.com> wrote in
| >> message
| >> >news:14****************************@phx.gbl...
| >> >> 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
| >> >
| >> >
| >> >.
| >> >
| >
| >
| >.
| >
Nov 19 '05 #6
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
-----Original Message-----
it sounds like none of your layers are doing any abstraction of the data, soa change in one, is a change in all. your components are too tightlycoupled. why does the Facade need details about product?

the Facade should be about data input, validation, and cross edits, andnavigation commands. the datums could be named e1-e20. you need to design astructure to pass data element to Facade, that gives the Facade the info itneeds (data validation rules, max length, captions, requirements, etc.)
-- bruce (sqlwork.com)

"V. Jenks" <an*******@discussions.microsoft.com> wrote in messagenews:1a****************************@phx.gbl...
| 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..
| >
| >"V. Jenks" <an*******@discussions.microsoft.com> wrote in
| message
| >news:04****************************@phx.gbl...
| >> 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...netarch001.asp
| >> >
| >> >"V. Jenks" <an*******@discussions.microsoft.com> wrote in| >> message
| >> >news:14****************************@phx.gbl...
| >> >> 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
| >> >
| >> >
| >> >.
| >> >
| >
| >
| >.
| >
.

Nov 19 '05 #7

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

5
by: Qp | last post by:
Hi, I've got a generic coding architecture question about an application I'm developing. Given that I've never developed anything quite like this before (especially not in Python), I'd appreciate...
0
by: DKode | last post by:
Ok, My company is asking me to build a portal site for managers. I think I have it down how I will structure the app, using C# and module based pages like in the ibuyspy portal example. I plan...
9
by: Rafael Charnovscki | last post by:
I can comprehend the basics of that subject (pointers, memory allocation, heap, stack etc), but I am interested to have references with more details. I have some C/C++ books and lots of URLs...
3
by: CSharpNewBie | last post by:
Hi I am looking to create a Plugin Architecture. I looked at this extend or enhance the User Interface (UI) article http://www.codeproject.com/csharp/extensibleui.asp and It looks good and I...
1
by: benmorganpowell | last post by:
I have a small windows service which connects to a POP3 server at defined intervals, scans the available messages, extracts the required information and inserts the data into a SQL database. I am...
4
by: Heath Kelly | last post by:
I need advice on correct usage of ADO.NET in an ASP.Net environment. I have an ASP.Net application that accesses data through a referenced class library. Things start to break down when multiple...
2
by: dydx13 | last post by:
Hello there, Basically, what I want to do is to develop a GUI-based file sharing program for myself. This is strictly for educational purposes only. Do you know of any good books out there that...
3
by: anthonykallay | last post by:
Hi there, I am building a website for a group that has 4 companies under it. The sites are fairly similar so i want to be able to use the same set of code in the App_Code folder.. I also want to...
13
by: terry.holland | last post by:
I have a three tiered CRM application (ASP.Net UI, VB.Net Business Layer & VB.Net Data Access Layer) that consists of number of classes. The application will be deployed to a number of clients. ...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.