Jorge,
If you're going to use Transfer instead of raw SQL, you're going to
need to do the following:
1) Add TransferFactory to your ColdSpring config.
2) Add Transfer to your ColdSpring config using factory-bean and
factory-method.
3) Add getters and setters to your DAO and Gateway objects to inject
Transfer into your persistence-layer objects.
4) Replace the contents of your DAO and Gateway objects with
getTransfer().methodCall(args), replace raw SQL with TQL, etc.
Your XML might look something like this when you're done:
<beans>
<bean id="TransferFactory class="transfer.TransferFactory">
<!-- property tags for TransferFactory config here -->
<property name="datasourcePath">
<value>/path/to/datasource.xml</value>
</property>
</bean>
<bean id="Transfer" factory-bean="TransferFactory" factory-
method="getTransfer" />
<bean id="FooGateway" class="com.data.foo.FooGateway">
<property name="Transfer">
<ref bean="Transfer" />
</property>
</bean>
</beans>
Transfer (for all but platform-specific SQL) replaces your
persistence layer and object model with its own view of the
universe... it creates your objects for you, the config file tells it
all it needs to know about your database and it autojoins all your
tables and everything, so you don't use raw, regular SQL in your
gateways and DAOs any more unless you need to. There are a few things
that it doesn't support, so for platform-specific queries (eg. using
SQL Server built-in stored procedures), use cfquery or
cfstoredprocedure.
One other quick point: I think I understand you to be saying that
Decorators are the "extra CFCs" that you referred to in your previous
post. If that's the case, then I have to say that yes, to really get
full use from Transfer you have to create "extra objects", although I
would follow that by saying that it's a mischaracterization of the
concept. Decorators are part and parcel to how Transfer is best
used... they're not "extra" anything, they're an essential part of
building a robust, capable collection of domain objects. Implementing
the behavior on the Decorators is how Transfer helps you achieve a
more fully OO architecture without burdening yourself with the time
and expense of creating a data tier on your own.
That is all for now. :) Have a good one!
J
On Nov 10, 2008, at 4:03 PM, Jorge Loyo wrote:
>
> J,
>
> Excuse my limited knowledge of transfer, but I was under the
> impression that a decorator acts as an extension of a bean... I would
> think that the use of any SQL or TQL would reside in the Data layer
> within a Gateway or DAO. ...
--~--~---------~--~----~------------~-------~--~----~
Before posting questions to the group please read:
http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer
You received this message because you are subscribed to the Google Groups
"transfer-dev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/transfer-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
