eigen framework / beheersysteem

Factory: een ontwerppatroon (zoekterm: Design Patterns), dat objecten voor je maakt. Je vraagt een bepaald soort object aan de Factory Method, en de verzameling klassen die daarachter zit, bepaalt wat je terugkrijgt.

Pimpel maakt nou net zo'n mooi subtiel onderscheid tussen parameters en services. Waarom heb je dat weggehaald?

En ook biedt het de mogelijkheid (op onbegrijpelijke wijze ;) ) alleen sommige services gedeeld te maken en andere niet, dat lijkt me ook erg handig.

Wat is het verschil tussen een 'Store' en een 'Repository'? Of is dat slechts naamgeving?

Pim - op 02/01/2011 23:59:10

Pimpel maakt nou net zo'n mooi subtiel onderscheid tussen parameters en services. Waarom heb je dat weggehaald?

Omdat ik die er nooit in heb gehad :) Die DependencyContainer heb ik zelf eens gemaakt, en tot nu toe heb ik niet echt de behoefte gehad er andere dingen in te stoppen dan objecten. Als ik er al parameters in stop, stop ik die in een service, bijv. Preference_Store oid, of Config.

Wat is het verschil tussen een 'Store' en een 'Repository'? Of is dat slechts naamgeving?

Puur naamgeving :) Een Store is voor mij gewoon iets waarin je objecten van een bepaalde class, in dit geval User, kan opslaan, en ze er ook uit kan halen. Deze store slaat het blijkbaar op in de database, aangezien hij PDO nodig heeft.

Jelmer rrrr op 03/01/2011 00:00:33

Een object of een functie of wat dan ook dat een object, een instantie van een class met al z'n benodigde parameters, voor je kan bouwen.

Oke... zoals ik al eerder gezegd heb heb ik geen ICT opleiding gevolgd.

Normaal maak ik een object als volgt, voorbeeld:

$user = new User();

Hoe zou dit met een factory gaan?

Oké nu sla je de plank echt mis. Moet morgen afstudeerverslag e.a. af hebben maar ik zal proberen hier kort en bondig op te reageren.

Mark PHP op 02/01/2011 21:35:47

[quote="The Force op 02/01/2011 21:17:23"]
Hoezo dat dan? Door niet zelf de queries te schrijven maak je je code abstracter. Je beschrijft meer wat je wil in plaats van hoe je dat wilt.

Wat is het verschil in $query = $this->select('x')->from('y')->where('z'); en $query = "SELECT x FROM y WHERE z"? Het eerste is omslachtiger. Het is een drogreden om te denken dat het eerste simpeler is omdat de developer dan geen SQL hoeft te kennen.
[/quote]

Dit is ook wel het meest simpele voorbeeld. Het wordt leuker als je automatisch arrays zonder dat je dan een loopje om z moet bouwen. Want waarom zou je dat zelf doen als een framework dat ook voor je kan doen? En waarom zou je standaard CRUD functionaliteit voor elke tabel willen maken en elke query zelf samenstellen als je dit ook generiek kan houden? Daarnaast in mijn voorbeeld wordt de query uitgevoerd en krijg je netjes een mooi resultaat terug waarbij rekening is gehouden met dat je een select doet. Jij hebt alleen nog een string die je moet uitvoeren en waarvandaan je verder moet werken. (Oke beetje onduidelijk uitgelegd miss.). De trend in programmeren van de komende vijf jaar is abstractie van code. Een extra laag zorgt voor extra abstractie. Je beschrijft het WAT en niet het HOE. Ik heb daar nog een mooie presentatie over gezien op de Microsoft Dev Days maar dat zoek ik later nog eens op.

Waar zeg ik overigens dat ik deze abstractie goed vind omdat het simpeler zou zijn omdat de developer geen SQL hoeft te leren?

Mark PHP op 02/01/2011 21:35:47

Daarbij aansluitend je tweede argument, dat Active Record je query aanpast naar standaard SQL. Dit wil je vaak niet, omdat je profijt wilt hebben van de trukjes, voordelen en functies die een specifieke database je biedt. Uiteraard zul je, als je ooit wil switchen naar een andere database, je queries hier en daar aan moeten passen. Maar zolang je alle SQL in een bepaalde applicatielaag hebt, is dit een peuleschil.

Waar zeg ik dat? Je query wordt echt niet aangepast naar standaard SQL. Active Record maakt gebruik van adapters. Elke DB heeft zijn eigen adapter. In een adapter kunnen leuke trucjes, voordelen en functies verwerkt worden. Een ander voordeel is dat deze adapter goed getest zijn dat deze dezelfde resultaten opleveren. Als jij zelf je queries gaat aanpassen dan moet je dit zelf testen. Weer een geval waar je niet met de HOE bezig wil zijn maar met de WAT. Als programmeur wil je bijv. 10 records inserten. Je gebruikt bijv. MSSQL. Multiple inserts is daar niet mogelijk dus hij doet netjes 10 aparte inserts. Je besluit MySQL te gebruiken of er komt een nieuwe versie van MSSQL die dat wel ondersteunt. Wat doe je? Je verwijst naar 'mysql' in de config en voila: multiple inserts. Je download een nieuwe MSSQL adapter voor de nieuwe versie en voila: multiple inserts.

Mark PHP op 02/01/2011 21:35:47

[quote="The Force op 02/01/2011 21:17:23"]In een situatie waar je 0 of meer WHERE statements kan hebben moet je als je zelf de query samenstelt counters gaan bijhouden of een hack als 'WHERE 0=1 ' toepassen zodat je daarna 'OR kolom=waarde' kan doen.

Ik kan me niet echt een situatie indenken waarbij je in PHP WHERE clausules aan elkaar gaat plakken.
[/quote]
De geavanceerde zoekpagina waarbij een gebruiker aan kan geven waarop hij wil zoeken? Dat iemand aanvinkt op achternaam te willen zoeken en een achternaam op geeft bijvoorbeeld? Zomaar een voorbeeldje, je kan er vast meer verzinnen.

Mark PHP op 02/01/2011 21:35:47

[quote="The Force op 02/01/2011 21:17:23"]Daarnaast dwingt Active Record automatisch veilige queries af door alles te escapen, door een XSS filter te halen enzovoorts.

Dit kan je ook afdwingen door een eigen Database klasse te schrijven, en alleen Prepared Statements toe te staan. Bovendien kan je adapters schrijven voor MySQL, PostgreSQL, Oracle enzovoort. XSS filteren doe je overigens niet als je data de database in moet, maar pas als je het aan de gebruiker presenteert.
[/quote]
[/quote]

Dat kan inderdaad.

Ozzie PHP op 03/01/2011 00:07:15

Hoe zou dit met een factory gaan?

Het idee is dat je een factory maakt omdat je op de plek waar je je User wilt aanmaken niet alle code en logica wilt hebben om zo'n ding daadwerkelijk aan te maken. User is een beetje ongelukkig voorbeeld, Mailer is misschien geschikter. Heel simpel gezegd:

<?php
function createMailer()
{
// haal configuratie op
// zoek er eventuele default waarden bij
// doe nog iets ingewikkelds
return new Very_Complex_SMTP_Mailer($config);
}

class Simple_Form_Controller
{
public function post()
{
$mailer = createMailer();

$mailer->send($email);
}
}
?>

Euhhh oke, maar wat is het verschil met jouw voorbeeld en met dit?

<?php
class Mail()
{

public function __construct() {
// stel configuratie en default waarden in
}

}

$mail = new Mail()
$mail->send($email);

?>

Ozzie PHP op 03/01/2011 00:22:11

Euhhh oke, maar wat is het verschil met jouw voorbeeld en met dit?

Zodat je je config en defaults code niet in je Mail class zelf hoeft te zetten. Stel je zou Zend_Mailer gebruiken. Die werkt nu met allemaal argumenten aan de constructor. Maar zou die gemaakt zijn zoals jij voorstelt, dan had je voor Zend_Mailer ook Zend_Registery en waarschijnlijk nog een aantal Zend_Config_* classes nodig gehad. Nu is het allemaal lekker los, niet meer afhankelijk van elkaar dan uiterst noodzakelijk. En dat maakt hergebruiken makkelijker.

Thanks voor je uitleg, maar kun je proberen die Zend dingen eruit te laten want die gebruik ik nooit en zeggen me dus ook niks :)

Maar als ik je goed begrijp...
Je hebt een bepaalde class en die class kan verschillende configuraties bevatten, afhankelijk van welke jij kiest. In de class zelf zet je dan de basis code en met die factory "injecteer" je de configuratie-instellingen. Correct?

In jouw geval... waar zet je dan de functie createMailer? Zet je die in een bepaalde class?

(ps ga zo mn bed opzoeken... lees morgen weer verder :))

Een klasse MailerFactory of eventueel meerdere bij elkaar: ServiceFactory, hoewel het eerste waarschijnlijk handiger is.