Re: [chiPHPug-discuss] OOP structuring question

[Wilfried S. <ws...@de...>]

This could be very expensive, but if you want to truly go all out OOP/ 
ORM-like, have you thought about returning an object instead of  
returning a list or array? This object could perhaps mirror/extend a  
pre-defined one, with functions that then go off and fetch the details?

Ex:
$member = new Member($member_id);
$photos = $member->getPhotos(where $query=''); //gets all photos,  
results in $photos
$details = $photos->getDetails(); //gets all details about $photos,  
results in $details? or perhaps getDetails() just populates $photos  
further, no need for the return? whatever is prettier to you.

with $member containing the member data in a way thats useful to the  
methodsin the object
with $photos containing the data of the getPhotos query thats userful  
to methods within a photos structure
with $details somehow containing some stdclass structure/array/ 
whatever that contains what youre looking for in an interable method.

This way you avoid having to iterate and do individual queries. Then  
again, you might actually want to do that. I don't know what your  
workload looks like or if it even matters. With the getDetails()  
function as above, it gives you the option to query as you'd like. I'd  
personally throw the IDs in a IN() query limited to 20 ids per each  
query, post multiget on my cache (The 20 limit is to avoid innodb mvcc  
deadlocks on high concurrency systems, ymmv).

I'd be interested to see how others disagree with me on this. I  
personally don't spend tons of time going out of my way to make my  
code all OOP'ed up just for the sake of OOP. For some things, OOP just  
isn't the right axe.


On Jun 10, 2009, at 13:33 , Arlo Leach wrote:

> Hi folks,
>
> I'm doing my first project with a fully object-oriented approach and  
> I have
> a question about how you all would break the code apart.
>
> Let's say I have a social networking site where members can upload  
> photos,
> and I want to display a particular member's photos.
>
> One approach is to have a Member object, with a method getPhotos, that
> returns the IDs of the photos that belong to that member; and to  
> have a
> Photo object, with a method getDetails, that returns the details for  
> a given
> photo. In order to display a member's photos, I would first call  
> getPhotos
> for the member, then call getDetails for each of the returned  
> photos. This
> makes sense from an encapsulation perspective, but it seems wasteful  
> because
> I'd have one initial database query plus an additional query for  
> each photo.
>
> I could build getDetails so that it can take a list of IDs and  
> return the
> details for all the photos at once, and then I'd just have two  
> queries. Or I
> could build a getPhotosByMember method that accepts a member ID as an
> argument and returns the details for all the photos belonging to that
> member. Then I'd be down to one query, but I would probably end up  
> building
> several similar methods (e.g., getRecentPhotos) that would have  
> redundant
> code.
>
> What would you say is the normal or accepted way to structure this?
>
> Thanks,
> -Arlo
>
> _______________________________
>
> Arlo Leach
> 773.769.6106
> http://arlomedia.com
>
>
>
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> chiPHPug-discuss mailing list
> chi...@li...
> https://lists.sourceforge.net/lists/listinfo/chiphpug-discuss