Re: Some architecture advice

From: Bijoy Naick (b_naick_at_yahoo.ca)
Date: 12/21/04 

Date: Tue, 21 Dec 2004 11:42:08 -0500

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

"V. Jenks" <anonymous@discussions.microsoft.com> wrote in message
news:145001c4e779$d466c320$a301280a@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

Relevant Pages

  • Some architecture advice
    ... I've used business objects for a while, ... make apps that are more maintainable. ... using a "bridge" pattern. ... On the UI layer I'll use a set of classes as a "facade" to ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: OO BASIC or "B++"?
    ... via xml from the UI to the persistence layer. ... Many apps use databasic ... lots of attention is Aspect Orientation (e.g. ... If you structure your app architecture correctly it becomes ...
    (comp.databases.pick)
  • Re: Some architecture advice
    ... >> I've used business objects for a while, ... each layer is independent of one another and each ... >> Being relatively inexperienced with architecture I'm sure ... >> database tables and I often have to call a single table ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Architectural Suggestion Needed
    ... What I'm used to is that the business objects are deployed on your middle ... layer, not the internal network. ... You would then use remoting to invoke the ... > Architecture 1 ...
    (microsoft.public.dotnet.framework.remoting)
  • Re: OBJECT-ORIENTED LAYERED ARCHITECTURE AND SUBSYSTEMS
    ... > OBJECT-ORIENTED LAYERED ARCHITECTURE AND SUBSYSTEMS ... > requirements of system owners, users, and clients. ... > code modules which all carry out the same necessary tasks for a layer. ... > each of those areas, or domains, constitutes a subsystem. ...
    (comp.object)
Loading