Re: [chiPHPug-discuss] OOP structuring question

[Kenneth D. <ke...@se...>]

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.
>   

OOP is an amazing and wonderful thing, when used in its context.

Discovering the context is simple in black-and-white cases.  The user 
interface lends itself very nicely to OOP concepts, and I've found UI's 
much easier to build with the OOP approach.

Mapping to the database is more of a gray area because the database 
operates on different principles.  Where the code meets the database you 
have a decision about how to proceed.

The ORM approach, which is what you are describing above, makes the 
database look like objects.  The problem is that a database is not a 
collection of objects.  As you say, "...it seems wasteful because I'd 
have on initial database query plus..."  That in a nutshell is what 
happens when the database is forced into the OOP mindset.

It's far more efficient to issues smart and efficient queries that 
return associative arrays, and then have classes that know what to do 
with those arrays.  A "photos" class need only know what to do with one 
or more photos, there is no reason that it must be used as 
one-object-per-row in the database.  As long as it knows what to do with 
photos, it should handle them in the most efficient way possible.  
Creating one object per database row is rarely the most efficient, if ever.

> 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
>   


-- 
Kenneth Downs
Cell: 631-379-0010
Fax: 631-689-0527
ke...@se...
http://www.secdat.com
http://www.andromeda-project.org