Re: Separate DAC from BO logic? What about physical assembly?

• Previous message: Don: ""There is no source code available for the current location""
• In reply to: Mike Hennessy: "Separate DAC from BO logic? What about physical assembly?"
• Next in thread: Mike: "Re: Separate DAC from BO logic? What about physical assembly?"
• Reply: Mike: "Re: Separate DAC from BO logic? What about physical assembly?"
• Messages sorted by: [ date ] [ thread ]

Date: Wed, 14 Jul 2004 14:21:34 -0600

"Mike Hennessy" <mhennessy@brassring.com> wrote in message
news:uVLVfrZaEHA.3508@TK2MSFTNGP09.phx.gbl...
> I'm looking for people's opinions and feedback regarding the
design of the
> application tier, and how to best logically separate out the
Data Access
> from the Business Object's. Per the Microsoft prescriptive
architecture
> documents, they recommend creating a completely separate
logical Data Access
> Tier of components. Then creating a separate tier of Business
Objects that
> consume them.
>
> My first question is...what does this actually buy you in the
real world?

It allows you to easily change from one database to another,
without having to rewrite a lot of your business code. For
example, you may have an application that you want to deploy to a
small company who just wants to use MySQL as a DB, but then you
may need to use this same app in a large enterprise that is
standardized on Oracle. By seperating out the data access
components, you merely switch which set they are using and
nothing else.

> Ok, if you need to in the future totally re-write your Data
access to a new
> Database server like Oracle or DB2, I can see separating out
the code.
> However, in the scenario where you know you will be writing to
a single DB
> server...what else does this approach buy you?

What happens when the Business Logic changes due to new laws or
requirements? When you have the data access intermingled all
throughout your business objects making changes to the business
logic may screw up your data access code.

>You'll be running the BO and
> DAC on the same physical server anyway. Also, adding that new
tier
> inherently add's to the complexity of your solution...you now
pretty much
> double the amount of classes, with each BO having a
corresponding DAC
> component. Is there other pros to this approach? As opposed to
having a
> single BO that contains your DAC methods directly?

Basically, if you are going to be able to write this app once,
and then never look at it again then it doesn't really matter.
However, in the real world this rarely ever happens. We find that
there are bugs, or new features required, etc.. By modularizing
your application as much as is logically possible, you can make
changes or fixes in one piece of code, and minimize the negative
impact it will have on other components.

Andrew Faust

• Previous message: Don: ""There is no source code available for the current location""
• In reply to: Mike Hennessy: "Separate DAC from BO logic? What about physical assembly?"
• Next in thread: Mike: "Re: Separate DAC from BO logic? What about physical assembly?"
• Reply: Mike: "Re: Separate DAC from BO logic? What about physical assembly?"
• Messages sorted by: [ date ] [ thread ]