eigen framework / beheersysteem
Pagina: « vorige 1 2 3 4 5 6 ... 10 11 12 volgende »
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.
Quote:
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.
Gewijzigd op 03/01/2011 00:07:30 door Jelmer -
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?
Mark PHP op 02/01/2011 21:35:47:
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.
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.
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:
Ik kan me niet echt een situatie indenken waarbij je in PHP WHERE clausules aan elkaar gaat plakken.
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.
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:
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.
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]
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:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Gewijzigd op 03/01/2011 00:17:36 door Jelmer -
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.
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 :))
Hoe is het principe van autoloading... Klopt de nu volgende gedachtengang of zit ik er helemaal naast?
Zodra je een class nodig hebt dan moet die "geladen" worden en volgens mij gebeurt dit via de magische __autoload functie. Klopt dat?
Dus stel je zegt $bla = new Bla() dan wordt de autoload functie getriggered en die vertaalt Bla naar library/Bla.php. Is dat de juiste gedachtengang?
Ik zou me nog kunnen voorstellen dat je een prefix aanbrengt om aan te geven dat het een bepaald type bestand is. Voorbeeld: $bla = new ModelBla(). Nu vertaalt de autooad functie ModelBla naar model/bla.php
Klopt dit nog allemaal wat ik zeg? Zo ja... waarvoor heb je dan include paden nodig, als je via de autload functie alles al regelt? Of klopt mijn bovengenoemde gedachtengang niet?
p.s. ipv $bla = new Bla() kun je ook zeggen $bla = new Bla. De laatste variant is zonder haakjes. Is het aan te raden om alleen haakjes te gebruiken als je variabelen meestuurt?
de include-paden helpen daarbij: je hoeft dan niet het volledige pad naar je klassedefinitie uit te spellen in __autoload().
Lees ook http://www.php.net/manual/en/language.oop5.autoload.php
Dus je zegt $bla = new Bla(). Autoload zegt include bla.php, en het bestand bla.php wordt gevonden omdat je de include paden hebt ingesteld. Correct?
Maar nu zou ik me kunnen voorstellen dat je je library pad en je model pad niet als include pad instelt, maar de volleidge url in je autoload functie stopt. Dus: include pad/naar/models/bla.php. Dan zeg je dus heel gericht tegen de php parser waar een bestand zich zou moeten bevinden. Is dat vanuit performance oogpunt niet beter? (werkt dit eigenlijk wel voor statiche functie aanroepen of gaat het dan sowieso mis).
p.s. ipv $bla = new Bla() kun je ook zeggen $bla = new Bla. De laatste variant is zonder haakjes. Is het aan te raden om alleen haakjes te gebruiken als je variabelen meestuurt?
__autoload() moet je wel *zelf* schrijven! Doe je daar alleen maar include bla.php, dan fikt het alsnog af wanneer het bestand niet bestaat, dat is het risico van het vak. Expliciete paden meegeven betekent ook dat je de indeling van je bibliotheken herhaalt in __autoload(). Een afrader.
Statische functies binnen een klasse maken ook van de klassedefinitie gebruik, en zorgen ook voor autoloading als de betreffende klasse nog niet aan boord is.
Ik zie dat je de haakjes mag weglaten. Waarom zou je dat doen? Ik schrijf ze altijd wel, naar analogie van het aanroepen van een functie.
Wat bedoel je hier mee? Ik snap dit niet helemaal.
"__autoload() moet je wel *zelf* schrijven! Doe je daar alleen maar include bla.php, dan fikt het alsnog af wanneer het bestand niet bestaat, dat is het risico van het vak. Expliciete paden meegeven betekent ook dat je de indeling van je bibliotheken herhaalt in __autoload(). Een afrader."
Ik snap dat je inderdaad een controle moet inbouwen, maar stel de je classes altijd in de map library staan en de models in de map models... waarom zou je dan niet de paden gebruiken? Dan heb je 2 minder include paden toch? Dat betekent minder zoekwerk voor de PHP parser dus een snellere afhandelnig van je request. Of slaat dit totaal nergens op wat ik nu zeg?
"Statische functies binnen een klasse maken ook van de klassedefinitie gebruik, en zorgen ook voor autoloading als de betreffende klasse nog niet aan boord is."
Ah oke, duidelijk :)
"Ik zie dat je de haakjes mag weglaten. Waarom zou je dat doen? Ik schrijf ze altijd wel, naar analogie van het aanroepen van een functie."
Ik schrijf ze ook altijd, maar kwam er een tijdje geleden toen ik een PHP boek las achter dat ze niet noodzakelijk zijn. Ik dacht eerst dat het een foutje van de auteur was :) Maar het werkt wel gewoon zonder haakjes, dus ik vroeg me af of er meer mensen zijn die de haakjes weglaten indien er geen variabelen zijn.
Je moet *niet* een architectuurbeslissing nemen omwille van "de performance", zeker niet als je niet kunt voorspellen hoeveel extra werk het je verderop gaat opleveren, en hoeveel performance dat zal kosten. Performance-tuning doe je beter aan een werkende applicatie, in de vorm van refactoring. (en tijdkritische systemen schrijf je niet in PHP)
__autoload() gaat bij elke niet-gevonden klasse af, of dat nu jouw 'classe' of 'model' is. Je moet dan dus op een of andere manier uitvinden waar je het bestand vandaan kunt includen; en dan is include_path zowel sneller als eleganter.
Bas Cost Budde op 03/01/2011 13:57:37:
Dit begrijp ik nog niet helemaal. Het 1e stukje snap ik, dat ie af gaat bij iedere niet gevonden class. Maar wat daarna komt snap ik niet helemaal. __autoload() gaat bij elke niet-gevonden klasse af, of dat nu jouw 'classe' of 'model' is. Je moet dan dus op een of andere manier uitvinden waar je het bestand vandaan kunt includen; en dan is include_path zowel sneller als eleganter.
Stel $bla = new ModelBla().
Ervan uitgaande dat het model pad geinclude is, zegt autoload nu:
include('bla.php') // alleen de bestandsnaam wordt geinclude.
Klopt dat? Zo ja, dan zou je toch ook het model pad niet als include pad kunnen instellen en er voor zorgen dat autoload dit doet:
include('pad/naar/models/bla.php')
Nu weet PHP direct waar het bestand gevonden kan worden en hoeven niet eerst alle include paden te worden afgespeurd.
Of zie ik het nu verkeerd?
Gewijzigd op 03/01/2011 14:28:22 door Ozzie PHP
The Force op 03/01/2011 00:08:01:
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.
Bijna enkele tabel is anders, daar kan je alleen door middel van omwegen iets generieks van maken. Bovendien wil je dat niet, omdat het dan niet in een oogopslag duidelijk is hoe je tabel eruit ziet. Dit vraagt om het maken van fouten, handmatig SQL schrijven is hier veel minder gevoelig voor.
Daarnaast leest ActiveRecord je database structuur in, dat kan niet anders. Aangezien je database structuur statisch is, is dit weggegooide performance.
Verder zal ik geen flauwe opmerking maken over de trend voor de komende 5 jaar. Wel vind ik dat alle queries in een laag houden genoeg abstractie. Je kan echter ook overdrijven. Bovendien heb ik begrepen dat het uitvoeren van ingewikkelde queries erg omslachtig is in bijvoorbeeld Doctrine.
The Force op 03/01/2011 00:08:01:
Waar zeg ik overigens dat ik deze abstractie goed vind omdat het simpeler zou zijn omdat de developer geen SQL hoeft te leren?
Nergens, was meer een algemene opmerking, daar veel voorstanders dit wel als argument aandragen.
The Force op 03/01/2011 00:08:01:
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.
Je zegt dat je alleen een configuratiebestand hoeft aan te passen als je van database wilt switchen. Dit impliceert voor mij dat je dan geen adapter specifieke functies kan gebruiken. Indien je toch vastzit aan een bepaalde adapter, vervalt het grootste deel van je punt van 02/01/2011 21:17:23.
Ook lijkt het mij onwenselijk dat ActiveRecord voor mij gaat bepalen hoe ik de database beheer. Ik houd ervan om alle touwtjes in handen te hebben, dus wil ik weten hoe mijn database omgaat met transacties, inserts, locks en noem zo maar op. Als ik dit weet kan ik optimaliseren op de manier die ik wil. Niet op de manier die ActiveRecord voor mij bepaalt.
Tenslotte weet ik niet precies hoe het aanmaken van klassen gaat binnen ActiveRecord. Indien dit, net zoals veel andere features, op magische wijze gebeurt, kan je het op de juiste plek controleren van data vergeten.
The Force op 03/01/2011 00:08:01:
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.
Voor het maken van een zoekfunctionaliteit raad ik je aan om eens te kijken naar tools die daarvoor bedoeld zijn, zoals Lucene of Sphinx. Veel makkelijker en sneller dan allemaal WHERE clausules in elkaar te knutselen.
Gewijzigd op 03/01/2011 15:10:35 door Mark PHP
In doctrine kan je trouwens ook een API gebruiken om een query te vormen.
Pagina: « vorige 1 2 3 4 5 6 ... 10 11 12 volgende »