jill han wrote:
The reason that I raised such question is that after the app was
evaluated, one of the issues is identified as
"The data tier of the application is not abstracted from the business
logic layer; so, any requirements to replace the data tier framework
(Torque) with other frameworks (e.g., Hibernate) will require extensive
changes to the business layer."
The recommendation is to " Abstract the data tier from the business
layer so that there is less overhead when replacing one framework with
other "
So your "consultants" are saying that you should invest more time *now*
abstracting the data tier because otherwise you *might* have to invest
time later to change the data tier? They are certainly earning their
fees *now* aren't they :-)
There are two fundamental realities you should be responding with:
1. It is unlikely that you will change the data tier, it is possible,
but is it likely?
2. If you switch to some other data tier you still have to get the
data in some form or another and it is highly likely that these
objects, as a matter of convenience and good OOD will provide
plenty of ways to access related data, which seems to be what is
being interpreted as violating your separation of tier rules.
So how big is this application? How many people are working on it?
Unless you have a multitude of programmers working on a very large
application with a high probability that the data access tier will be
replaced then I would call BS.
The fact of the matter is that if there was a possibility that you would
be replacing the data tier in the future then you would have done this
already or commence doing it today. The time you would spend now adding
any kind of abstraction to allow replacement of the data tier would
probably outweigh or come close to the amount of time you would need to
actually replace it (your consultant is advising you to spend real
dollars now to allow for something there is only a possibility of
occurring in the future). The abstraction layer would be worth the
effort if you were going to be replacing the data tier several times in
the future or if you were producing a solution that allowed end users to
pick from a selection of data tiers, but I think the first of these
reasons is an absolutely insane thing to plan for and the second is just
plain silly - select the data tier framework that 80% of your customers
are going to choose anyway and commit to it.
Maintaining an absolute separation of these tiers is not going to help
you produce software in an efficient manner - the gains in doing so are
IMHO questionable in most cases.
Scott
I just want to hear the other voices to see how they think about this
kind of design issue.
Thanks,
Jill
-----Original Message-----
From: David Demner [mailto:[EMAIL PROTECTED]
Sent: Monday, May 21, 2007 7:09 PM
To: 'Turbine Users List'
Subject: RE: business tier and data tier
Hi Jill,
Since the Torque Generator generates om.Base* classes (which handles all
the
database access [ie: data tier]), which are then extended by the om.*
classes (which can handle the business logic [ie: business tier]), which
are
then referenced by velocity. So even though the files are in the same
package, I don't consider them to have violated any application design
principles.
Regards,
David
-----Original Message-----
From: jill han [mailto:[EMAIL PROTECTED]
Sent: May-21-07 8:50 AM
To: Turbine Users List
Subject: business tier and data tier
If this kind of subject is not supposed to be discussed in the group, I
apologize.
I use turbine/torque/velocity in the application. In the java object
class, the objects that retrieve data through torque are created in
order to be referenced in the velocity template.
Is this kind of practice violating the rule of separating business tier
from data tier?
Thanks for your help as always,
Jill
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
