[PHP] OOP vraag

[chuxiej]

Beste Tweakers,

Al een aantal jaar ben ik professioneel bezig met PHP.
Nu is er iets dat mij al een tijdje weerhoud van het maken van mijn projecten volgens OOP.
Ik vraag me namelijk af hoe het nou precies zit met de performance van het volgende.
Stel ik heb een webshop en wil dit OOP doen.
Ik heb een Child class Product, bij het aanroepen hiervan haald de class de data hiervan uit de database.
Stel nu ik wil 50 producten uit de database halen dan betekend het dus dat er 50 queries worden uitgevoerd terwijl dit eigelijk gewoon in 1 query zou kunnen met een while loop.
Toch is dit echter de manier dat (volgens mij) OOP werkt maar is dit niet heel erg voor de performance van de webshop?

Ik hoop dat ik mijn vraag een beetje goed formulier.
Er zijn al diverse tutorials die ik heb bekeken maar er staat nergens iets over de performance.

[storeman]

Tja, je kunt op twee manieren werken, je kunt elk product zijn eigen informatie laten verzamelen vanuit de database. Je kunt ook een create functie maken, welke elk product apart aanroept. Op die manier heb je dus een hogere functie de de query uitvoert en vanuit deze query voor elke rij een nieuw product creeerd.

Op zich is dit niet zo'n verkeerde manier, jij wilt dat elk child voor zichzelf kan zorgen, in de praktijk zal dat nooit gebeuren, er is altijd externe informatie nodig, of ieder child die zelf ophaald uit de database of met behulp van setter functies wordt ingegeven, maakt voor de werking niet zoveel uit.

[LuCarD]

Waarom zou je opeens 50 queries moeten doen om de produkten op de halen? OOP verandert daar echt niet aan hoor..

Performance is voor mijn gevoel verwaarloosbaar, programmeertijd is voor mijn gevoel aanzienlijk lager.

[DemonTPx]

Je zou natuurlijk ook een soort van Lijst-class kunnen maken, waarin je alle producten als array oid zet. Die class zou dan in een query alle producten kunnen ophalen.

[user109731]

Je kunt toch een (static) function getProducts ofzo maken? Daarin maak je dan een database object, verwerk je alles en geef je een array met Product-objecten terug.

1 query per product is onzin, daar word je server niet blij van...

[ Voor 4% gewijzigd door user109731 op 08-10-2007 10:59 ]

[prototype]

Ik denk dat je je even wil verdiepen in object relational mapping (ORM), en misschien in het bijzonder de ActiveRecords variant. Kort door de bocht voor jou wordt daarin gewerkt met statische finder methoden van de modelklasse die dan met 1 query de data zoeken m.b.v. de gegeven constraints en met de factory method van de model klasse een collectie van instanties van dat model teruggeven.

In ruby on rails ziet dat er b.v. zo uit (en op praktisch analoge wijze geschiedt het ook zo in ActiveRecord implementaties voor PHP):

Ruby:

products = Product.find(:all, {:conditions => [ "category = ?", category ] })

De statische find methode van de klasse Product (waarbij Product een afgeleide is van ActiveRecord::Base) voert bij aanroep een query uit met de gegeven parameters. Adhv deze queryresultaten wordt in een lus voor elke resultaat een Product geinstantieerd en tegevoegd aan een collectie. Deze collectie wordt vervolgens geretourneerd, en products bevat deze dan.

[chuxiej]

Bedankt iedereen hier heb ik veel aan, ik ga me even verder verdiepen maar het is in grote lijnen duidelijk.

[Verwijderd]

storeman schreef op maandag 08 oktober 2007 @ 10:50:
Tja, je kunt op twee manieren werken, je kunt elk product zijn eigen informatie laten verzamelen vanuit de database. Je kunt ook een create functie maken, welke elk product apart aanroept. Op die manier heb je dus een hogere functie de de query uitvoert en vanuit deze query voor elke rij een nieuw product creeerd.

Op zich is dit niet zo'n verkeerde manier, jij wilt dat elk child voor zichzelf kan zorgen, in de praktijk zal dat nooit gebeuren, er is altijd externe informatie nodig, of ieder child die zelf ophaald uit de database of met behulp van setter functies wordt ingegeven, maakt voor de werking niet zoveel uit.

Ik heb me zelf ook afgevraagd hoe ik een class moet schrijven waarmee ik op een efficiente object georienteerde manier meerdere rijen kan doorlopen.

Zelf heb ik nog weinig tijd gehad om me hier in te verdiepen.
Maar met de SPL classes wordt zoiets wel bereikt, ik denk dat we zo'n soort structuur ook nodig hebben. Dus het zal zoiets als de volgende iteratie classes moeten worden denk ik:

www.php.net/spl

[base_]

Kijk hier eens mbt ORM mbv propel/symfony:
http://www.symfony-projec...08-Inside-the-Model-Layer

[Janoz]

Een complete ORM implementeren vind ik in php onzin. Het zou nut gehad hebben wanneer php een applicationscope had gehad. Veel ORM's hebben een initiele overhead. Bij een platform als .NET, Ruby of J2EE maakt dat niks uit omdat dit alleen tijdens het starten van de server of webapplicatie optreed. Bij php heb je deze overhead bij elk request.

Voor php applicaties zou ik persoonlijk niet verder gaan dan het toepassen van het DAO pattern. Gewoon een class die verantwoordelijk is voor het ophalen van specifieke gegevens. Deze retourneert vervolgens of enkel een product object, of een array met product objecten.

[Brakkie]

Of Doctrine. De meest geavanceerde ORM voor php tot nu toe. Kan ook in Symphony gebruikt worden.

http://www.phpdoctrine.net/index.php/

[SchizoDuckie]

Ik heb dit in m'n eigen O/R mapper / active record ding ook op een zelfde manier opgelost:

PHP:

$products = dbObject::Search('Product' , array('Category'=>'TestCategorie')); // className, filters

if($products) // returned false als er niets gevonden is
{
  echo('<table>');
  foreach($products as $product)
 {
   echo("<tr><td>{$product->Name}</td>{$product->Price}</td></tr>");
 } 
  echo('</table>');
}

Zo laat je de OR mapper zelf afhandelen hoe hij moet zoeken, en krijg je een lijst met gevulde objecten terug

Overigens zal ik heb ik zojuist mn huidige versie die ik gebruik weer eens online gezet want daarin is nogal wat opgeschoond/verbeterd

[ Voor 16% gewijzigd door SchizoDuckie op 08-10-2007 12:57 ]