Handling the loading of object relationships
tm8747a
as to how to handle loading object relationships. The easiest way to
illustrate is probably by example.
Suppose I have a Team component and a Player component. As a team has
many players, I'd want to have a getPlayers() method for my Team
component that would retrieve the associated players for a team (done
using lazy loading, of course). This is technically not too
complicated to do and I can think of various ways to automate
relationships, but it seems I'd need to inject something into my bean
to do so and I'm not sure it's appropriate. My bean would need to
access some data access component like DataMgr, or a Player DAO, or a
service that can provide a list of players, in other words, some
external way of getting to my players. From a design standpoint, is it
a bad thing to inject those into your bean? If so, what are the
drawbacks/use cases that make this a bad thing and what would be a
better way of going about it? If not, then I guess I'm a happy guy and
not as confused as I thought!
Justin Scott
> team has many players, I'd want to have a getPlayers() method for
> my Team component that would retrieve the associated players for
> a team (done using lazy loading, of course).
I think you have the general idea already. If you were using ORM this
is exactly what it would do under the hood. If you have a "Players"
property on a component which is a relationship with a "Player" table
then it will create a getPlayers() method which returns an array of
associated "Player" objects. ORM handles this under the hood, but if
you're coding your own DAOs, then one object will need to use the DAO
of a related object to load its data. Encapsulation is still
maintained as long as the Team object is going through the Player DAO
and not directly to the database.
-Justin
Thomas Messier
this. I might as well dig deeper and see if my overall plan is sound
or if I'm overlooking anything. I'm not a huge fan of a lot of DAOs/
Gateways, so I wasn't even planning on using them. My idea was as
follows: I'm going to use services, iterating business objects (IBOs)
instead of regular beans, and a generic data access layer (either
something like DataMgr or one generic DAO). So basically, I would do
most data operations in my services by calling DataMgr/DAO and if
queries get stupidly complicated (which they will, this is a re-write
of an existing app so I know what I'm up against) I can do those
queries in straight SQL in the service function itself. Moreover,
while I remember seeing services always returning objects on "get"
functions, I was thinking of returning queries instead. The reasoning
behind it is that if my service layer is basically going to be the API
to my app, seems like returning objects is not a good idea given that
some front ends accessing the app could be in something other than CF
and as such can't deal with CF objects. The other option would be to
include an argument to specify the return type, but seems like an
unnecessary extra step. It wouldn't be a big deal when I do a get
operation to just get an IBO object from my bean factory in my
controller, call the service layer for the "get" operation that
returns a query, and just load the query into the IBO. Funny, now that
I typed this, seems like a lot of work. hehehe Might need to think
about it some more.
So I have 2 doubts:
1) Is it OK to be doing queries directly in my services. Or would it
really be a big pain to not have the data access completely abstracted
out of it. I could use individual DAOs extending a generic DAO and
implement custom functions when needed, but just seems like overkill.
2) Is there a good reason my services should always return objects on
get operations (bearing in mind I'm using IBOs, so no big object
creation penalty), or is returning queries fine given the case I
explained above (other front ends)?
Thanks again for any feedback,
-TM
James Buckingham
1) Is it OK to be doing queries directly in my services. Or would it
really be a big pain to not have the data access completely abstracted
out of it. I could use individual DAOs extending a generic DAO and
implement custom functions when needed, but just seems like overkill.
Absolutely not :-). By abstracting from the service you're opening this and the querying to other uses. What if I wanted to provide your services with a querying from a different database or a Web Service? What if I wanted to use your querying in another service or completely different application?
Abstraction = more flexibility.
2) Is there a good reason my services should always return objects on
get operations (bearing in mind I'm using IBOs, so no big object
creation penalty), or is returning queries fine given the case I
explained above (other front ends)?
No good reason at all. Not everything has to be an object :-)
Cheers,
James
Salvatore FUSTO
related player collection: if you have to display players, a simple query is
sufficient and efficient, on the other hand if you have to interact with
players collection in a team object(update or delete a player), may be an
ibo is better.
If you have to navigate thru the players, you can wrie an iterate based on
an array of struct, first converting a players query.
Also don't forget circular reference: a team as a collection of players, and
a players as a team: when you instantiate a team, you instantiate a
collection of player objects, in every player you instantiate a team in
which you instantiate a collection of player and so on.
salvatore
-----Messaggio originale-----
Da: coldfu...@googlegroups.com [mailto:coldfu...@googlegroups.com] Per
conto di Thomas Messier
Inviato: venerdì 20 aprile 2012 14.53
A: Object-Oriented Programming in ColdFusion
Oggetto: [coldfusionoo] Re: Handling the loading of object relationships
-TM
--
You received this message because you are subscribed to the Google Groups
"Object-Oriented Programming in ColdFusion" group.
To post to this group, send email to coldfu...@googlegroups.com.
To unsubscribe from this group, send email to
coldfusionoo...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/coldfusionoo?hl=en.
Thomas Messier
Thomas Messier
On Friday, April 20, 2012 10:56:50 AM UTC-4, salvatore fusto wrote:
As always, it depends. it depends on what you have to do with the the
related player collection: if you have to display players, a simple query is
sufficient and efficient, on the other hand if you have to interact with
players collection in a team object(update or delete a player), may be an
ibo is better.
If you have to navigate thru the players, you can wrie an iterate based on
an array of struct, first converting a players query.
Also don't forget circular reference: a team as a collection of players, and
a players as a team: when you instantiate a team, you instantiate a
collection of player objects, in every player you instantiate a team in
which you instantiate a collection of player and so on.
salvatore
-----Messaggio originale-----
Da: coldfu...@googlegroups.com [mailto:coldfusionoo@googlegroups.com] Per
For more options, visit this group at
http://groups.google.com/group/coldfusionoo?hl=en.
On Friday, April 20, 2012 10:56:50 AM UTC-4, salvatore fusto wrote:
As always, it depends. it depends on what you have to do with the the
related player collection: if you have to display players, a simple query is
sufficient and efficient, on the other hand if you have to interact with
players collection in a team object(update or delete a player), may be an
ibo is better.
If you have to navigate thru the players, you can wrie an iterate based on
an array of struct, first converting a players query.
Also don't forget circular reference: a team as a collection of players, and
a players as a team: when you instantiate a team, you instantiate a
collection of player objects, in every player you instantiate a team in
which you instantiate a collection of player and so on.
salvatore
-----Messaggio originale-----
Da: coldfu...@googlegroups.com [mailto:coldfusionoo@googlegroups.com] Per
Salvatore FUSTO
I use another solution,: consider the example team/player, where team class have a collection of players, and player class have a team;
I implement a basic player class, with a simple property corresponding to the FK of its own team, and an extended player class(extPlayer extends basicPlayer) with the team object as a property, then in my team class I implement a collection of basicPlayers as property, on the other and when I need to instantiate a player, I instantiate expPlayer: I’d be interested on what do you think about.
Regards
Salvatore Fusto
Ps
About “per conto di…” I’m in italia and may be gmail would facilitate my reading J
Da: coldfu...@googlegroups.com
[mailto:coldfu...@googlegroups.com] Per conto di Thomas Messier
Inviato: venerdì 20 aprile 2012 18.48
A: coldfu...@googlegroups.com
Oggetto: Re: [coldfusionoo] Re: Handling the loading of object
relationships
If I'm understanding what you're bringing up correctly, I don't think circular references will be an issue. If I weren't lazy loading all the time it could be a major issue, but since I intend to always lazy load one-to-many relationships, I think it ought to be fine. As a side note, I'm really digging the stuff that got copied from the emails. " Per conto di Thomas Messier". Awesomeness!
-TM
On Friday, April 20, 2012 10:56:50 AM UTC-4, salvatore fusto wrote:
As always, it depends. it depends on what you have to do
with the the
related player collection: if you have to display players, a simple query is
sufficient and efficient, on the other hand if you have to interact with
players collection in a team object(update or delete a player), may be an
ibo is better.
If you have to navigate thru the players, you can wrie an iterate based on
an array of struct, first converting a players query.
Also don't forget circular reference: a team as a collection of players, and
a players as a team: when you instantiate a team, you instantiate a
collection of player objects, in every player you instantiate a team in
which you instantiate a collection of player and so on.
salvatore
-----Messaggio originale-----
Da: coldfu...@googlegroups.com
[mailto:coldfu...@googlegroups.com]
Per
For more options, visit this group at
http://groups.google.com/group/coldfusionoo?hl=en.
On Friday, April 20, 2012 10:56:50 AM UTC-4, salvatore fusto wrote:
As always, it depends. it depends on what you have to do
with the the
related player collection: if you have to display players, a simple query is
sufficient and efficient, on the other hand if you have to interact with
players collection in a team object(update or delete a player), may be an
ibo is better.
If you have to navigate thru the players, you can wrie an iterate based on
an array of struct, first converting a players query.
Also don't forget circular reference: a team as a collection of players, and
a players as a team: when you instantiate a team, you instantiate a
collection of player objects, in every player you instantiate a team in
which you instantiate a collection of player and so on.
salvatore
-----Messaggio originale-----
Da: coldfu...@googlegroups.com
[mailto:coldfu...@googlegroups.com]
Per
For more options, visit this group at
http://groups.google.com/group/coldfusionoo?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Object-Oriented Programming in ColdFusion" group.
To view this discussion on the web visit https://groups.google.com/d/msg/coldfusionoo/-/0Y5AegBU8pcJ.
To post to this group, send email to coldfu...@googlegroups.com.
To unsubscribe from this group, send email to coldfusionoo...@googlegroups.com.