Hey dude...
Yeah, my original message was about 3x longer than the one I actually
sent in... but a big part of it was focused on the fact that in the
current project I'm on we're doing just that: treating Transfer as
though it were a replacement for a "traditional persistence layer".
Decorated TransferObjects serve as domain objects, implementing
almost all behavior there while the service layer just handle object
instantiation and high-level persistence for save(Object) and
cascadeSave(Object) calls.
We've been happily putting TQL (and even raw SQL in a few places) is
either in the Decorator classes (this is where there's raw SQL with
cfquery tags) or in the Service classes (no SQL there, just lots of
TQL). We're pretty much working with the philosophy that Transfer is
a parallel to the DAO/Gateway concept. While I know that others
disagree, and that's cool, this is working quite nicely and we're not
seeing any maintainability issues to speak of. Everything is still
encapsulated and cohesive, the function of the domain objects is to
carry the business rules of the application and the services handle
object instantiation and persistence.
We're calling Transfer.get("objName",arguments.id) for object
instantiation, and we're calling either Transfer.save
(arguments.Object) or Transfer.cascadeSave(arguments.Object) for
persistence, all in the Service classes. The rest of the business
logic is implemented in decorators and, for the most part, the
controllers do nothing but pull data from the controllers (you'd call
them listeners in M2) and translate that into method calls on
Services to fetch an object, populate with data from the event and
save; or to fetch an object from Transfer and stick it into the event
for use in a view.
We're pulling the actual objects down into the view where their API
is used to fetch data for the view. Again, this is a controversial
topic but it's working quite well, we're able to use the decorated
TransferObjects to manage implementations that are as generic as
possible for servicing as many views with one method as we can, and
we're still not seeing any maintenance headaches. We're pretty much
taking a pragmatic approach that delegates as much as possible to
Transfer itself while using the decorators to apply whatever custom
code we may need for specific situations.
Hope that helps... I know moving to Transfer and taking a more object-
centric domain-oriented kind of approach can be a disorienting and
aggravating process, but in the long run it's worth it.
Laterz,
J
On Nov 11, 2008, at 10:38 AM, Jorge Loyo wrote:
>
> J,
>
> Thank you for your response...
>
> Let me ask you, unless I need any custom SQL/TQL, is it really
> necessary to create the DAO and/or Gateway CFCs? or would calling
> transfer methods like listByPropertyMap or readByPropertyMap directly
> from the service be ok?
>
> Thank you in advance.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
