Separate DAC from BO logic? What about physical assembly?

  • Thread starter Thread starter Mike Hennessy
  • Start date Start date
M

Mike Hennessy

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

The next question is, say that you do choose to have a separate DAC tier.
Now..when creating your assemblies, how do people recommend breaking out the
code as far as projects and solutions? For example, I have seen solutions
which create a separate DAC project and put a majority of their DAC classes
in there. This creates a physical assembly which now needs to be accessed
from the BO. Doesn't this impose an unnecessary performance penalty?

The other option is to creat separate projects based on core functionality
and include both the BO and DA classes in that single project. They then get
deployed as a single assembly and you remove the overhead of separate
assemblies.

Is there a best practice here? What's the pros/cons that people see?

Thanks for your feedback!
 
Mike Hennessy said:
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
Click to expand...
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?
Click to expand...

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?
Click to expand...

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
 
Hi Andew, thanks for the reply.

You said in your message:
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.
Click to expand...

I'm NOT suggesting writing Data Access code directly in a BO method.
What I'm saying is that, yes, create separate DAC methods...but create
them in the BO directly, instead of creating a totally separate class
file. This still keeps the DA logic separate, but it's in the same BO.
Per your question above, regardless of whether those methods live in the
BO or in a separate DAC, you will STILL have to make the change to a
component. In my case, you can make the changes in a single component,
where in your case, you will make a change to the BO AND the DAC
component. Again...I don't see how the physical separation buys you
anything UNLESS you are planning on being able to change your DB
backend.

Is that pretty much the argument?
 
Back
Top