De PHPhulp kroeg
OOP gedachtengang
Pagina: « vorige 1 2 3 4 5 volgende »
Allereerst even voorop gesteld dat de discussie op Twitter / Facebook ging over Zend en Symfony (Dus MVC en HTTP framework)
Daarom zei ik dat Wouter fan is van het HTTP framework Symfony en ik / kees en andere fan ben van het Zend MVC framework.
Quote:
Maar ik denk dat als je frameworks gaat presenteren, je twee betere keuzes had kunnen maken, namelijk micro-framework vs full-stack-framework
Ondanks bovenstaande verklaring, even nog een reactie op deze zin. Ik ben direct begonnen met het realiseren van projecten met Zend framework. Ik heb dus nooit een framework like Silex gebruikt. Ik kan dus niet beoordelen of het in het 'framework-leer-proces' beter is om te beginnen met een klein framework. Er zijn ook mensen die zeggen dat je beter kan beginnen met het bouwen van een eigen framework.
Mijn mening is, dat je pas een eigen framework moet bouwen als je geen framework kan vinden wat aan jouw eisen voldoet. Aangezien er behoorlijk wat frameworks zijn, is dat dus (haast) nooit het geval.
Wat de eisen van een framework zijn, laat ik in het midden.
Quote:
Because I really don't care whether Symfony2 is MVC or not. Probably because the MVC word is so overloaded and because nobody implements exactly the same MVC pattern anyway.
Ik twijfelde of ik die nog moest opnemen in mijn verhaal. Ik heb het niet gedaan aangezien Fabien het volgende zegt:
Quote:
I don't like MVC because that's not how the web works. Symfony2 is an HTTP framework; it is a Request/Response framework. That's the big deal. The fundamental principles of Symfony2 are centered around the HTTP specification.
Hij vind MVC niets aangezien het web zo niet werkt. Dat betekend dus dat hij een framework heeft gemaakt dat niet op het MVC pattern lijkt, aangezien hij daar niet van houd. Anders spreekt hij zichzelf tegen toch?
Quote:
Because I really don't care whether Symfony2 is MVC or not.
ORM:
Wat ik nog als discussie punt wil stellen. Is een ORM eigenlijk wel gewenst? Werkt dat nu echt zo lekker als het allemaal voorgeschoteld wordt. Is het niet veel mooier om gewoon query's te tikken zonder al die rompslomp?
Wat is nu precies het voordeel van een ORM?
Het voordeel van deze techniek is dat je code niets af hoeft te weten van het soort database dat gebruikt wordt. Hierdoor wordt het eenvoudig om van database te switchen. Daarnaast maakt dit de rest van je programma eenvoudiger. Je kan rechtstreeks met de tabellen werken zonder dat je ingewikkelde mappers of iets dergelijks hoeft te maken.
Maar, heb jij wel eens in een project van een type database moeten switchen? En als dat zo is, getuigd dat niet van een slecht voorbereiding?
En heb je met een ORM wel eens geprobeerd een zeer ingewikkelde query te schrijven? ééntje met flink wat joins, unions, subquery's (voor zover je subquery's mooi vind), group by's en nog wat lastige zaken?
Maar goed, zegt iemand, daar heb ik een oplossing voor. De meeste ORM's bieden ook de mogelijkheid om een normale query te tikken. Maar ben je dan niet je database onafhankelijkheid (Wat juist zo'n groot voordeel van een ORM is) kwijt? En op het moment dat je meerdere van zulk soort query's hebt, wordt je applicatie dan geen bende?
Het tweede 'voordeel' van een ORM is dat je tabellen naar objecten map waardoor de communicatie met de database een stuk eenvoudiger is. Echter, waarom moet je een ORM hebben om dit te bereiken? Waarom niet gewoon wat mooie data mappers? Zijn die nou zo moeilijk om te schrijven? Je bereikt dan toch precies hetzelfde? Het voordeel van wat mooie mappers is dat je gewoon lekker query's kan bakken zonder al die rompslomp eromheen.
Dat is naar mijn mening ook één van de grootste nadelen van een ORM. Doordat je een taal (SQL bijvoorbeeld) probeert te abstraheren / evenaren / nabouwen / geef het beest een naampje, wordt je code algauw enorm ingewikkeld. Waar is de tijd gebleven dat je nog netjes query's schreef?
Nog een nadeel van een ORM is, is dat ze nooit doen wat je exact wilt. De ene gebruikt backticks de andere doet het weer fout met haakjes, en noem maar op.
Ooit wel eens nagedacht over query optimalisatie? Weet jij exact hoe je dit doet in jouw ORM?
En als je nu iets database gerelateerd wilt schrijven? Hoe ga je dat doen? Schrijf je dan wel ineens een normale query? Is dat niet hypocriet dan?
Tot slot:
Hopelijk begrijp je dat bovenstaande verhaal een beetje overtrokken en sarcastisch geschreven is, maar ik hoop dat ik een (leuke) discussie oproep.
Mooi topic dit, daarvoor ben ik hier op PHPhulp!
Niels Kieviet
Gewijzigd op 21/06/2012 15:55:01 door Niels K
En van DB wisselen in een project slechte voorbereiding? Ik heb een tijdje met RoR gewerkt (die gebruikt Active Record) en daar is het de standaard dat je in develop mode een SQLite DB gebruikt en in productie mode een MySQL db (oid). Dus ik denk niet dat het iets te maken heeft met slechte voorbereiding...
Quote:
Mijn mening is, dat je pas een eigen framework moet bouwen als je geen framework kan vinden wat aan jouw eisen voldoet. Aangezien er behoorlijk wat frameworks zijn, is dat dus (haast) nooit het geval.
Natuurlijk, maar Silex is al een framework. Je hoeft niet zelf een framework te bouwen.
Even een voorbeeldje met een gastenboek systeem:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
<?php
require_once __DIR__.'/vendor/Silex/autoload.php';
$app = new Silex\Application();
// beetje Twig is altijd leuk
$app->register(new Silex\Provider\TwigServiceProvider(), array(
'twig.path' => __DIR__.'/views',
));
$guestBookMapper = new Guestbook\Mapper();
// als guestbook wordt opgeroepen in de url
$app->match('/guestbook', function() use ($app, $guestBookMapper) {
// haal de 10 laatste berichten op
$posts = $guetsBookMapper->getRecent(10);
// render de show_all.twig page met de 10 recentste berichten
return $app['twig']->render('show_all.twig', $posts);
});
// als guestbook/show/12 wordt opgeroepen (of elke andere id)
$app->get('/guestbook/show/:id', function(Silex\Application $app, $id) use ($guestBookMapper) {
// kijk of bericht bestaat
if ($post = $guestBookMapper->getById($id)) {
// ja, hij bestaat, render show_single.twig met de gegevens van het bericht
return $app['twig']->render('show_single.twig', $post);
} else {
// nee, hij bestaat niet :( toon 404 pagina
$app->abort(404, 'Dit bericht bestaat niet');
}
});
?>
require_once __DIR__.'/vendor/Silex/autoload.php';
$app = new Silex\Application();
// beetje Twig is altijd leuk
$app->register(new Silex\Provider\TwigServiceProvider(), array(
'twig.path' => __DIR__.'/views',
));
$guestBookMapper = new Guestbook\Mapper();
// als guestbook wordt opgeroepen in de url
$app->match('/guestbook', function() use ($app, $guestBookMapper) {
// haal de 10 laatste berichten op
$posts = $guetsBookMapper->getRecent(10);
// render de show_all.twig page met de 10 recentste berichten
return $app['twig']->render('show_all.twig', $posts);
});
// als guestbook/show/12 wordt opgeroepen (of elke andere id)
$app->get('/guestbook/show/:id', function(Silex\Application $app, $id) use ($guestBookMapper) {
// kijk of bericht bestaat
if ($post = $guestBookMapper->getById($id)) {
// ja, hij bestaat, render show_single.twig met de gegevens van het bericht
return $app['twig']->render('show_single.twig', $post);
} else {
// nee, hij bestaat niet :( toon 404 pagina
$app->abort(404, 'Dit bericht bestaat niet');
}
});
?>
Gewijzigd op 21/06/2012 16:11:08 door Wouter J
Je draait om het punt heen ;-) Ik wil niet weten of het kan, ik wil weten wat jij er van vind. Ondanks mijn verhaal gebruik ik (af en toe) wel een ORM. Simpelweg omdat het makkelijk is.
Maar sinds ik een aantal artikelen gelezen heb, heb ik een andere mening gevormd. Ben jij het daar mee eens?
Quote:
Symfony laat in het midden wat je doet met die DB, dat is nou zo mooi. Beslis zelf niet wat jij het best vind, maar laat de uiteindelijke gebruiker beslissen welke 3th party hij gebruikt. Precies zoals met Twig, vind je Smarty mooier? Dat kan zo!
Zeker! Dat vind ik juist zo mooi aan Symfony, het laat je helemaal vrij, terwijl Zend dat juist niet doet. Alhoewel dat ook niet helemaal waar is. Met zend kan je ook bepalen wat je wel en niet doet. Dus wel of geen Doctrine, of wel of geen Smarty / Twig.
Alleen heb ik wel mijn bedenkingen omtrent een template parser. Waarom moet dat? Kan jij nu echte voordelen opnoemen?
Quote:
En van DB wisselen in een project slechte voorbereiding? Ik heb een tijdje met RoR gewerkt (die gebruikt Active Record) en daar is het de standaard dat je in develop mode een SQLite DB gebruikt en in productie mode een MySQL db (oid). Dus ik denk niet dat het iets te maken heeft met slechte voorbereiding...
Ik bedoelde te zeggen dat, dat juist één van de voordelen van een ORM is, maar dat je zulk soort situaties bijna niet tegenkomt.
Ik zeg altijd, een goede ontwikkelomgeving staat gelijk aan de live omgeving.
Quote:
Natuurlijk, maar Silex is al een framework. Je hoeft niet zelf een framework te bouwen.
Exact, maar dat bedoelde ik niet. Ik gaf alleen een reden waarom je evt een eigen framework / beheersysteem (Zie ook topic van Ozzie PHP van een aantal maanden geleden) kan schrijven.
Tot slot,
Code voorbeeld ziet er goed uit. Ik heb niets tegen Silex? Alleen ik probeer mensen na te laten denken i.p.v iets klakkeloos over te nemen. Je moet geen framework gaan gebruiken omdat andere mensen het aanraden of omdat andere mensen zeggen dat het een goed framework is.
Of ben je dat niet met mij eens?
Dankjewel voor je antwoord!
Niels Kieviet
Gewijzigd op 21/06/2012 19:18:59 door Niels K
Quote:
Je draait om het punt heen ;-) Ik wil niet weten of het kan, ik wil weten wat jij er van vind. Ondanks mijn verhaal gebruik ik (af en toe) wel een ORM. Simpelweg omdat het makkelijk is.
Maar sinds ik een aantal artikelen gelezen heb, heb ik een andere mening gevormd. Ben jij het daar mee eens?
Maar sinds ik een aantal artikelen gelezen heb, heb ik een andere mening gevormd. Ben jij het daar mee eens?
Tja, zoals ik net al had gezegd heb ik nog geen groot project gemaakt en nog maar weinig met ORM's gewerkt, maar ik vind het wel fijn werken. En ja, er zitten nadelen aan, maar goed. Ik ben van mening dat aan elke libary/framework/app/pattern voordelen zitten en nadelen.
Quote:
Code voorbeeld ziet er goed uit. Ik heb niets tegen Silex? Alleen ik probeer mensen na te laten denken i.p.v iets klakkeloos over te nemen. Je moet geen framework gaan gebruiken omdat andere mensen het aanraden of omdat andere mensen zeggen dat het een goed framework is.
Nee, het was ook niet om jou van Silex te overtuigen. Het was om dit topic, en Jasper, een voorbeeld te geven van hoe het ook kan. Om een voorbeeld te geven van een micro-framework in gebruik. Juist omdat ik het volledig eens ben met het laatste dat je zegt. Je moet niet iets klakkeloos overnemen, je moet zelf opzoek gaan naar wat jij het best vind werken.
Daarom heb ik eerst aan alle 3 de frameworks gesnuffeld en vervolgens begonnen met Symfony. Waarom? Nou allereerst omdat de website en documentatie van Symfony er het best uitzag (ja, ben en blijf een webdesigner). En ten tweede toch zeker wel omdat de code veel moderner was met de nieuwste technieken (Silex maakt zelfs al gebruik van traits(!)).
En een template parser, goed of niet?
Zie daarvoor: http://www.phphulp.nl/php/forum/topic/template-engine-doen-of-niet-doen/83080/
Samengevat, ik hou van template parsers omdat:
1) het makkelijker is om te leren (voor designers), want (dit gaat over Twig) de syntax lijk redelijk op JavaScript. Iets wat designer met jQuery nu wel redelijk doorhebben.
2) het goede support heeft voor blocks en extenden van templates
3) autoescaping
4) designer beperken => zorg dat de designer niet alles kan doen zodat er geen grote fouten ontstaan
5)
Bedankt voor dit leuke topic en er zullen binnenkort waarschijnlijk wel wat ZEND vragen van mijn kant komen! ;-)
EDIT:
nog even over de gedachtengang, ik denk dat ik een beetje moeite heb met het opsplitsen van een echte pagina naar een view, controller, moddel.
Ik heb 2 pagina's : index.php (-> basis info + taal kiezen) , login.php (-> formpje om in te loggen) Zijn dat nu 2 aparte controllers of 1 controller met een action "login" als ik "Each page of the application is known as an action and actions are grouped into controllers" in mijn achterhoofd hou?
Gewijzigd op 21/06/2012 21:25:31 door Jasper DS
Deze 2 taken hebben ieder een eigen controller. Dan heb je nu al die dingen die er binnen zo'n taak gedaan worden, vaak de CRUD (create, read, update en delete). Dit zijn acties, ook heb je vaak een show actie.
Vervolgens heb je ook verschillende tabellen: users (voor inlog systeem) en posts (voor de berichten). Elke tabel krijg zijn eigen Model.
Ik vind die engelse quote een beetje vaagjes en niet echt geweldig...
Toevoeging op 21/06/2012 22:47:38:
Niels, ben ik op de goede weg?
Code (php)
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
<?php
/**
* Dit is het Guestbook object waar ik al mijn info uit kan trekken via de controller, de info haal ik uit de Mapper
*/
class Application_Model_Guestbook extends Zend_Db_Table_Row_Abstract
{
protected $id;
protected $comment;
protected $email;
protected $date;
public funtion __set($name, $value)
{
if(method_exists($this,$name='set_'.$name))
{
return $this->$name($value);
}
else
{
trigger_error($name.' is not avaliable .',E_USER_ERROR);
}
}
public function __get($name)
{
if(method_exists($this,$name='get_'.$name))
{
return $this->$name();
}
else
{
trigger_error($name.' is not avaliable .',E_USER_ERROR);
}
}
// ik denk dat ik de setters en getter nog moet maken?
public function getId()
{
return $this->id;
}
public function setId($id)
{
$this->id = $id;
}
// Wat moet er in deze classe nog worden toegevoegd?
}
?>
/**
* Dit is het Guestbook object waar ik al mijn info uit kan trekken via de controller, de info haal ik uit de Mapper
*/
class Application_Model_Guestbook extends Zend_Db_Table_Row_Abstract
{
protected $id;
protected $comment;
protected $email;
protected $date;
public funtion __set($name, $value)
{
if(method_exists($this,$name='set_'.$name))
{
return $this->$name($value);
}
else
{
trigger_error($name.' is not avaliable .',E_USER_ERROR);
}
}
public function __get($name)
{
if(method_exists($this,$name='get_'.$name))
{
return $this->$name();
}
else
{
trigger_error($name.' is not avaliable .',E_USER_ERROR);
}
}
// ik denk dat ik de setters en getter nog moet maken?
public function getId()
{
return $this->id;
}
public function setId($id)
{
$this->id = $id;
}
// Wat moet er in deze classe nog worden toegevoegd?
}
?>
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
<?php
/**
* Dit object haalt info uit de db en stopt dat in het Guestbook object
*/
class Application_Model_GuestbookMapper {
protected $dbTable;
public function setTable(Zend_Db_Table_Abstract $table)
{
$this->dbTable = $table;
}
public function getTable()
{
return $dbTable;
}
public function save(Application_Model_Guestbook $guestbook)
{
// Ik veronderstel dat ik hier mijn data uit het object Application_Model_Guestbook moet halen?
$this->getTable()->insert($data);
}
public function fetchAll()
{
// Tabelobject? Wat is mijn tabelobject?
}
}
?>
/**
* Dit object haalt info uit de db en stopt dat in het Guestbook object
*/
class Application_Model_GuestbookMapper {
protected $dbTable;
public function setTable(Zend_Db_Table_Abstract $table)
{
$this->dbTable = $table;
}
public function getTable()
{
return $dbTable;
}
public function save(Application_Model_Guestbook $guestbook)
{
// Ik veronderstel dat ik hier mijn data uit het object Application_Model_Guestbook moet halen?
$this->getTable()->insert($data);
}
public function fetchAll()
{
// Tabelobject? Wat is mijn tabelobject?
}
}
?>
Wouter J:
Tja, zoals ik net al had gezegd heb ik nog geen groot project gemaakt
Ik had je uitgenodigd toch ? ;-)
Wouter J:
... en nog maar weinig met ORM's gewerkt, maar ik vind het wel fijn werken. En ja, er zitten nadelen aan, maar goed.....
Dat klopt, ze werken inderdaad fijn. Maar zodra je echt een moeilijke query wilt bakken wordt een ORM al gauw lastig. Zijn er mensen die deze ervaring delen?
Quote:
... Ik ben van mening dat aan elke libary/framework/app/pattern voordelen zitten en nadelen.
Daar heb je een goed punt! :-) Elke framework heeft wel zijn ditjes en zijn datjes. Maar een framework is iets anders dan een ORM ;-)
Wouter J:
Nee, het was ook niet om jou van Silex te overtuigen. Het was om dit topic, en Jasper, een voorbeeld te geven van hoe het ook kan. Om een voorbeeld te geven van een micro-framework in gebruik.
Ah, sorry dan heb ik dat verkeerd geïnterpreteerd. Zoals ik zei kan ik daar niet over oordelen omdat ik direct met Zend Framework begonnen ben. Dat heb je als je bij een bedrijf pas echt begint met programmeren.
Wouter J:
Juist omdat ik het volledig eens ben met het laatste dat je zegt. Je moet niet iets klakkeloos overnemen, je moet zelf opzoek gaan naar wat jij het best vind werken.
Kijk, we komen er wel uit ;p
Wouter J:
Daarom heb ik eerst aan alle 3 de frameworks gesnuffeld en vervolgens begonnen met Symfony. Waarom? Nou allereerst omdat de website en documentatie van Symfony er het best uitzag (ja, ben en blijf een webdesigner). En ten tweede toch zeker wel omdat de code veel moderner was met de nieuwste technieken (Silex maakt zelfs al gebruik van traits(!)).
Top, iedereen zijn eigen favorite framework toch? Ik vind zowel Zend als Symfony lekker werken. (Heb 1 project met Symfony gedaan)
Ik heb echter veel meer verstand van Zend Framework dan van het Symfony framework dus als ik wat dingen uitleg probeer ik het op basis van Zend Framework te doen.
Wouter J:
En een template parser, goed of niet?
Zie mijn reactie in het desbetreffende topic.
@Jasper PHP
Ik heb geen tijd meer om op jouw reactie te reageren. Its party time ;-) Ik zal morgen op jouw reactie reageren.
of zou dit niet uit moeten maken.
Quote:
Maar een framework is iets anders dan een ORM ;-)
Daarom zei ik ook framework/libary/app/pattern, ik denk dat een ORM daar wel ergens tussen valt :)
Maar ben je al begonnen met symfony? Of begrijp je het niet? (vertel maar even in je eigen topic, houden we de zaken goed gescheiden)
Edit:
Even iets opgezocht waardoor je ziet dat ik niet de enige ben die dit vind:
Quote:
In addition to the content of the Quick Tour I also found the design of Symfony’s website to be quite appealing. Although it is said to not judge a book by its cover we humans tend to notice things that are pretty. The same is true of Symfony’s website. Its pleasing to look at, pleasing to use, and I felt a sense of professionalism and polish that made me feel safe to learn more about the code.
I spent a few nights reading in bed on my iPad the rest of Symfony’s tutorials and docs and finally felt confident enough to begin coding. I did begin doing some coding in Symfony and aside from the difficulty of learning a new project’s jargon I was actually having an enjoyable time using Symfony.
(bron)
I spent a few nights reading in bed on my iPad the rest of Symfony’s tutorials and docs and finally felt confident enough to begin coding. I did begin doing some coding in Symfony and aside from the difficulty of learning a new project’s jargon I was actually having an enjoyable time using Symfony.
(bron)
Gewijzigd op 23/06/2012 10:16:49 door Wouter J
De werking snap ik helemaal, alleen je gebruikt voor de eerste keer dat je een object aanmaakt een andere naam voor object, dat lijkt mij juist verwarrend.
Klopt dit?
Dan heb je /www/classes/User/User.php en als je dan new User doet, dan kom je daar uit?
En, ja dat staat heel lelijk en ja dat kan veel mooier. Met namespaces:
Code (php)
1
2
3
4
5
6
7
8
9
10
2
3
4
5
6
7
8
9
10
<?php
// lib/MyProject/User/User.php
namespace MyProject\User;
class User
{
// ...
}
?>
// lib/MyProject/User/User.php
namespace MyProject\User;
class User
{
// ...
}
?>
Code (php)
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
<?php
// index.php
// registreer de autoloader
use MyProject\User\User;
$user = new User();
?>
// index.php
// registreer de autoloader
use MyProject\User\User;
$user = new User();
?>
En het is lazy-loading: De klasse wordt pas ingevoegd als je hem nodig hebt, niet eerder.
Vind het toch mooier om er Application_Model_DbTable_Settings te typen als
Pagina: « vorige 1 2 3 4 5 volgende »