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