[PHP] Design Pattern

[g4wx3]

Graag wil ik jullie mening horen over het design pattern in mijn nieuwe site.

Uiteraard verwacht ik kritieken maar dan wil ik weten hoe jullie het zouden aanpakken, of veranderen.
Zelf heb ik ook reeds bedenkingen, maar..
1 Het werkt perfect en flexibel
2 Ik heb probeerde dingen te veranderen, maar het is mislukt (bijv om de class op te splitsen)

Radicaal veranderen of opnieuw beginnen ga ik niet doen, dat versta ik niet onder verbeteringen
Maar bijvoorbeeld ik heb nog geen database connectie geimplementeerd
Dit is de volgende stap. ik heb mijn ideeen hieromtrend, maar ben evenzeer benieuwd naar jullie ideeen
(uiteraard gebruik ik hier PDO, maar dat is eerder implementatie dan design)

De site heb ik geschreven from scratch juist om mijn php-skills opfrissen.
Uiteraard ben ik meteen begonnen met OOP, en mijn doel was een MVC-pattern.

Ik heb nooit lessen gehad en totaal geen ervaring met bestaande MVC-framework.
Wel heb ik er al heel veel theorie over gelezen.

ik wil de broncode wel delen als er vraag is.
Maar nu zal ik het "design pattern" zo schematisch mogelijk weergeven
ik weet welliswaar niet hoe ik die het beste doe, ik probeer met een lijstje+uitleg

Folder structure:
om alvast een idee te hebben, begin ik met de mappenstructuur
Ik gebruik de echte maar deze zijn volledig arbitrair gekozen.

• index.php = loader configuratie
• core/
  • loader.php = class loader
  • (not yet) db.php = class db(database acces code )
• pages/
  • base=template
    • meta.php = controller
    • html.php = view
    • (not yet) table.php = model
    • css.php
  • session
    • meta.php = controller
  • *home*
    • meta.php = controller
    • html.php = view
    • home_alternatief.php = view alternatief
    • (not yet) table.php = model
    • css.php = (optional css)

Program flow:

• loader = new loader()
• loader->set_root('pages')
• loader->set_page('session','session')
• loader->set_page('template','base')
• loader->set_page('main','home')
• loader->load_controllers()
  • pages/session/meta.php
  • pages/base/meta.php
  • pages/main/meta.php
    • process input(GET&POST)
    • (not yet) open dataBase conection
    • (not yet) load table.php, insert, update, delete
• loader->load_html('template')
  • pages\base\html.php
    • include(menu)
    • $this->load_html(main) = pages/home/html.php
      • Select from table
      • output html
    • include(footer)

Wat gebeurt er

De index maakt een nieuw object van loader.
Via dit object gebeurt alle interactie
Eerst worden standaard pagina's ingesteld
Vervolgens zal $_GETworden ingelezen door de loader om te weten welke controllers er nodig zijn.
Vervolgens zal van iedere pagina in volgorde de controller worden aangeroepen.

Een tekort koming is dat een controller zelf geen andere controllors meer kan toevoegen aan de loader.
Wel kan de controller een andere view initieren, dan de standaard html.php

Als laatste worden alle views opgeroepen in volgorde.
Views zullen zelf data moeten ophalen uit de database.

Het lijkt inflexible, maar ik geraakt er behoorlijk goed mee uit de voeten
Maar ik ben benieuwd naar jullie mening.

[Anoniem: 26306]

g4wx3 schreef op woensdag 24 december 2014 @ 22:53:

Views zullen zelf data moeten ophalen uit de database.

Nee, dat moeten views juist niet. Die moeten alleen bezig zijn met het weergeven van data uit de model en het doorgeven van user-interactie aan de controller.

Een view kan bijvoorbeeld de gewenste HTML genereren. Als je dan een PDF versie wilt, zou het mooi zijn als je slechts een andere view moet instantieren.

Als je views data gaan ophalen dan ben je niet bezig met MVC.

[Ramon]

Het is voor mij al een tijdje geleden dat ik met PHP en MVC bezig ben geweest dus neem mijn commentaar voor wat het waard is. Een paar dingen die mij opvallen:

- Waar komen de namen meta.php, html.php en table.php vandaan (en zet je er achter wat het daadwerkelijk is?) Waarom niet gewoon controller.php, view.php, en model.php? In je code doe je het zo te zien wel goed.
- Waarom is er een onderverdeling met een pages-directory? Dat vraag ik omdat bijvoorbeeld een bepaald model op meerdere pages terug kan komen, dan wil je die niet moeten dupliceren per page. Dan is het handiger om alle models bij elkaar te steken (bijv in één directory of in één bestand). Hetzelfde geldt eigenlijk voor de controller.

Een tekort koming is dat een controller zelf geen andere controllors meer kan toevoegen aan de loader.
Wel kan de controller een andere view initieren, dan de standaard html.php

Ik vraag me af in hoeverre dat daadwerkelijk een tekortkoming is. Een controller geeft als resultaat een gerenderde view terug, dus vanuit de ene controller een andere controller aanroepen zou raar zijn. Als je de gebruiker door wilt sturen naar een andere pagina dan maak je een controller die een 301 of 302 aan de browser teruggeeft.

[Saven]

Even globaal het topic doorgelezen, maar waarom niet een framework kiezen dan wordt heel je werkwijze eigenlijk al vastgelegd. Bijvoorbeel Kohana of CodeIgniter, die zijn relatief makkelijk te gebruiken en ook MVC

[g4wx3]

@Ramon:

• meta.php was logischer controller geweest, maar bij de eerste aanroep was dit om head-tags toe te voegen, zoals title, css, enzovoort, achteraf gezien, nog veel meer, maar de naam heb ik (nog) niet verandert.
• De onderverdeling, is onstaan omdat ik begon met statische html pagina's, en alles wat bij de pagina haart, zoals JS, CSS, Images in een map zette, de naam van de map komt dan weer in de url.
• De modellen zal ik inderdaad beter in 1 directory steken, zoals je aangeeft, zal ik vanuit meerdere controllers toegang willen hebben.
• Het feit dat een controller geen andere controller kon aanroepen, dwingt inderdaad om de juiste GET-parameters mee te geven. Zo wou ik het mail formulier op meerder plekken includen, wat makkelijk gaat. Om de verwerking te laten gebeuren, moest de mail-controller worden aangeroepen.
• >>Na eerst wat te ver te zoeken, was dit eenvoudig opgelost door bij de action-parameter een extra request naar de mail controller te plaatsen, maar het deed me nadenken over het design. Vandaar dus ook dit topic.

@Saven

• Ik zal jou suggestie zeker bekijken. Mijn doel was om te beginnen from scratch, om zo mijn stoffige PHP-kennis terug op te frissen. Ik had een vermoeden dat ik te veel hooi zou nemen op de vork door te beginnen met een veel te groot framework

[ Voor 23% gewijzigd door g4wx3 op 25-12-2014 01:15 ]

[Saven]

Geloof me ik wilde vroeger ook alles zelf maken, maar kost veel te veel tijd om goed te onderhouden en met de tijd mee te gaan. Met zo'n framework hoef je je echt alleen te focussen op je applicatie. En als het even kan gebruik ik voor klanten gewoon een Joomla of Wordpress site, of Prestashop webshop maakt het leven zoveel gemakkelijker. Enige nadeel is dat het je tijd kost om je te verdiepen in deze (complexe) systemen. Maar als jij van 0 af aan een framework maakt kost je dat evenveel tijd.

[Barryvdh]

Begin eens met een PSR-0 of PSR-4 autoloader te gebruiken, bij voorkeur gewoon Composer met die autoloader. Geef dan al je classes logische namespaces en namen, dus bijv. Pages\HomeController class in Pages/HomeController.php
Zie https://getcomposer.org/doc/01-basic-usage.md#autoloading

En maak maak dan ook een public map, wat de html root is, met je assets en index.php, de rest hoeft niet bereikbaar te zijn.

En je hoeft niet perse direct een framework gebruiken, maar je kan wel componenten gebruiken, zoals een Database ORM, een router of template engine.

Want je loader is nu je router dus? En heb je meerdere controllers per route? Of is altijd meta de enige controller?
Heb je je code toevallig op Github staan al?

[cyberstalker]

Ik vraag me altijd af hoe mensen het voor zich zien dat ze met puur PHP een MVC-implementatie bouwen. Hoe update je een view op het moment dat een wijziging binnenkomt? Daar heb je eigenlijk websockets voor nodig, waar PHP bij uitstek ongeschikt voor is. Imiteer je dit dan via polling o.i.d.?

[Ramon]

cyberstalker schreef op donderdag 25 december 2014 @ 12:13:
Ik vraag me altijd af hoe mensen het voor zich zien dat ze met puur PHP een MVC-implementatie bouwen. Hoe update je een view op het moment dat een wijziging binnenkomt? Daar heb je eigenlijk websockets voor nodig, waar PHP bij uitstek ongeschikt voor is. Imiteer je dit dan via polling o.i.d.?

Ik vraag me eerder af waarom jij ervan uitgaat dat "realtime" updaten onderdeel is van MVC?

[RobIII]

Wat heeft (near)realtime updates van een view met MVC te maken?

En @TS: waar is het design pattern dan? (topic titel). Een design pattern lost een specifiek (deel) probleem op en doet alléén dat. En dat doet het bij voorkeur in een abstracte, consistente manier. If anything dan zie ik in dit topic alleen maar anti-patterns, NIH syndroom en halfslachtige geïmplementeerde (flarden van) design patterns. Ik zie hier meer iets dat van een "framework" weg heeft dat een design pattern. Ik zou de wikipedia pagina (of GOF boek!) er nog eens bij pakken... Je zegt een hoop gelezen te hebben maar ik zie vooral een boel klepels en klokken.

[ Voor 21% gewijzigd door RobIII op 25-12-2014 12:44 ]

[Cartman!]

Misschien zonde van je werk maar ik zou toch overstappen naar een framework als Symfony 2, Silex of Laravel. Die dwingen je meestal al in een bepaald patroon waar over nagedacht is en het neemt je enorm veel werk uit handen.

Verder heeft MVC niks met realtime updates te maken inderdaad.

[Barryvdh]

Hier misschien een interessant artikel over MVC wat ook het realtime updaten bespreekt: http://blog.ircmaxell.com...guide-to-mvc-for-web.html

[WinstonC]

Sinds een aantal maanden gebruik ik voor nieuwe klanten ook een MVC look-a-like framework wat ik zelf heb ontwikkeld en nog steeds ontwikkel. Hieronder staat de structuur, misschien dat je er wat aan hebt.

- index.php (Verwijst naar de juiste omgeving)
-- Backend (Beheer omgeving)
--- Handlers
--- Services
--- ViewModels
--- Views
-- Frontend (Website omgeving)
--- Handlers
--- Services
--- ViewModels
--- Views
-- Shared (Functionaliteiten)
--- Base (base classes voor handlers, repositories en services).
--- Helpers
--- Models
---- Annotations (XML bestanden)
--- Repositories

Ik heb nog niet zo iets als routing, daarvoor gebruik ik nu nog simpelweg de htaccess wat prima is op dit moment. De repositories, handlers, models, services en enkele helpers zijn allemaal objecten en de rest niet.

Verder gebruik ik niet de namespaces functie van PHP, maar verwijs ik naar het PHP bestand via een aparte functie waardoor het zelfde soort idee ontstaat.

[Cartman!]

http://symfony.com/pdf/Symfony_book_2.6.pdf hier staat een mooi voorbeeld van "flat php" vs Symfony 2 wat denk ik goed het nut van een framework kan uitleggen.

Waarom mensen nog steeds denken een eigen framework te moeten maken is me een raadsel.

[cyberstalker]

MVC is origineel ontwikkeld voor user interfaces. Een van de problemen die het oploste was dat er meerdere views konden zijn die dezelfde data (of een deel van dezelfde data) weergeven. De views luisteren hierbij naar de controller en het model om updates binnen te krijgen.

Op deze manier wordt het harde werk van het synchroon houden van de gegevens uit de handen van de programmeur gehouden. Elk MVC-framework wat dit niet doet heeft dus niets met MVC te maken.

[Barryvdh]

cyberstalker schreef op donderdag 25 december 2014 @ 12:55:
MVC is origineel ontwikkeld voor user interfaces. Een van de problemen die het oploste was dat er meerdere views konden zijn die dezelfde data (of een deel van dezelfde data) weergeven. De views luisteren hierbij naar de controller en het model om updates binnen te krijgen.

Op deze manier wordt het harde werk van het synchroon houden van de gegevens uit de handen van de programmeur gehouden. Elk MVC-framework wat dit niet doet heeft dus niets met MVC te maken.

Php frameworks gebruiken inderdaad nooit het originele MVC pattern, maar meer MVC als concept om je applicatie op te delen (separation of concerns) en elk framework heeft hier weer een variant op. Het idee is globaal meestal wel hetzelfde, zoals veel beter wordt uitgelegd in het blog artikel uit mijn vorige reactie..

Barryvdh schreef op donderdag 25 december 2014 @ 12:49:
Hier misschien een interessant artikel over MVC wat ook het realtime updaten bespreekt: http://blog.ircmaxell.com...guide-to-mvc-for-web.html

Ik ben het er wel mee eens dat je beter een framework kan gebruiken, dat wat meer richtlijnen geeft, zeker als je nog niet heel bekent bent met MVC of OOP.. En anders iig componenten gebruiken.
Persoonlijk ben ik wel fan van laravel, dat vond ik makkelijker als Symfony om mee te beginnen.
En als je het toch zelf wil doen, lees deze serie eens door: http://fabien.potencier.o...ymfony2-components-part-1

[ Voor 19% gewijzigd door Barryvdh op 25-12-2014 13:13 ]

[Xantios]

Saven schreef op donderdag 25 december 2014 @ 00:03:
Even globaal het topic doorgelezen, maar waarom niet een framework kiezen dan wordt heel je werkwijze eigenlijk al vastgelegd. Bijvoorbeel Kohana of CodeIgniter, die zijn relatief makkelijk te gebruiken en ook MVC

Kohana ken ik verder niet, toffe naam wel
ben de docs even aan het doornemen, echt groot lijkt het niet ?
( al hoeft dit geen reden te zijn om het niet te gebruiken vind ik )

CodeIgniter zou ik even mee wachten, die zijn nog niet zo lang overgenomen van EllisLab door British Columbia Institute of technology

Het ding is dus wel dat zij CI redelijk willen gaan verbouwen ( terecht ook wel )
maar momenteel gebruiken ze de 2.0 branch dus nog.

lijkt me niet heel handig om daar nu op in te haken als je nog nooit een framework gebruikt heb.

al moet ik zeggen, ik ben ooit ook begonnen met CodeIgnitor als eerste framework, en gebruik er nu meerdere ( waaronder overigens ook customs, soms moet dat nu eenmaal )

[Saven]

Xantios schreef op donderdag 25 december 2014 @ 13:10:
[...]


Kohana ken ik verder niet, toffe naam wel
ben de docs even aan het doornemen, echt groot lijkt het niet ?
( al hoeft dit geen reden te zijn om het niet te gebruiken vind ik )

Klopt is redelijk lichtgewicht en niet zo complex als bij voorbeeld Zend Framework. En er zit een heel nice ORM systeem in

[willyb]

Je core en pages mappen hoeven nooit te worden aangeroepen door een bezoeker? Plaats ze dan buiten je webroot.

[_Moe_]

Saven schreef op donderdag 25 december 2014 @ 13:54:
[...]

Klopt is redelijk lichtgewicht en niet zo complex als bij voorbeeld Zend Framework. En er zit een heel nice ORM systeem in

Ikzelf maak ook al enkele jaren gebruik van Kohana, maar ben van plan om in de nabije toekomst over te schakelen op Laravel. Dit omdat Laravel meer mee is met de nieuwste technieken en het naar mijn gevoel ook fijner werkt. Verder heeft deze ook een veel ruimer publiek waardoor je ook allerhande documentatie kan vinden op het net.

[ Voor 9% gewijzigd door _Moe_ op 25-12-2014 20:17 ]

[WinstonC]

Waarom mensen nog steeds denken een eigen framework te moeten maken is me een raadsel.

De reden dat ik een eigen framework, wat ik liever niet zo noem omdat het nog lang niet zo compleet is als andere bekende PHP frameworks is, heb gemaakt is om mijn PHP OOP skills te vergroten, geen zin had in het kiezen van een framework om daar vervolgens eerst tegen van alles en nog wat aan te lopen en omdat ik zeker weet dat ik de geschreven code grotendeels kan gebruiken voor verschillende klanten. That's why.

[Barryvdh]

Waarschijnlijk leer je veel meer over OOP als je een modern framework goed gebruikt. Anders ga je iets maken waar je over een paar maanden al niet meer mee verder kan. Een framework heeft over het algemeen juist wel goede ondersteuning, is meer flexibel en je kan het makkelijker overdragen indien nodig.

Tenzij je natuurlijk al ruime ervaring hebt met OOP en precies weet wat je nodig gaat hebben in je toekomstige projecten en al je werknemer/scollega's makkelijk het framework kan leren. Maar 99% van de eigen frameworks voegen weinig toe.

[mindcrash]

Barryvdh schreef op donderdag 25 december 2014 @ 20:45:
Waarschijnlijk leer je veel meer over OOP als je een modern framework goed gebruikt. Anders ga je iets maken waar je over een paar maanden al niet meer mee verder kan. Een framework heeft over het algemeen juist wel goede ondersteuning, is meer flexibel en je kan het makkelijker overdragen indien nodig.

Plus security. Zo'n beetje alle OSS web frameworks (onder om het even welke programmeertaal) worden bijzonder zwaar aan de tand gevoeld wat security issues en features betreft. Veel devs, zeker beginnende devs, onderschatten vaak de mogelijke security holes die kunnen ontstaan naarmate de complexiteit toeneemt. En ook al ben je vrijwel fulltime als team aan zo'n framework aan het sleutelen, of zo ontzettend skilled zijn dan nog kunnen security issues vanwege wat voor reden dan ook opduiken. Rails is bijvoorbeeld hierbij een ontzettend goed voorbeeld.

Een ander punt, rechtstreeks uit de praktijk: Geen enkele klant (tenminste, de klanten die ik ken) zit te wachten op uren die gefactureerd worden op zogenaamde non-functionals oftewel alle componenten die niet direct een bijdrage leveren aan de functionaliteit en dus hun omzet (tijd/geld/beide). Eigen frameworkje bouwen in je eigen tijd als experiment is misschien interessant, maar in de tijd van de klant kan (of liever gezegd: gaat) men aan de andere kant nogal moeilijk doen (al helemaal als je trots verteld dat naast onderhoud aan alle functionele features, ook onderhoud aan non-functionele features noodzakelijk is omdat je als dev team wat last hebt van NIH. Want meer onderhoudskosten.) Dus pak je voor de core van je app een framework als Phoenix, Rails, Sinatra, Express, Laravel, Symphony of wat je dan ook handig vind voor je huidige situatie/programmeertaal en stop je je tijd en energie in het bouwen van functionele features, waar je ook ontzettend veel architectuur en design patterns en werk in kunt steken, al helemaal als je als architect een platform neerzet op basis van iets als SOA/microservices. Dat zijn immers de dingen waar klanten *wel* geld/tijd mee verdienen en dus ook waarvan ze bereid zijn om (veel) geld neer te leggen. En dit soort dingen op een goede, robuuste wijze bouwen (zeker als je met zoiets als gedistribueerde omgevingen - CQRS/ES and friends - aan de gang gaat) is zelfs vaak al moeilijk en tijdrovend zat. -

Samenvattend: leer bijvoorbeeld ontzettend goed bestaande frameworks toepassen, in-process of out-of-process business logica te ontwerpen en bouwen d.m.v. bijvoorbeeld Domain Driven Design en hoe bestaande of nieuwe systemen of services (of webbased APIs) te integreren in je app en/of platform. Een software engineer die dit vrij vlot *en* goed kan, kan werkelijk waar overal aan de slag.</rant>

[ Voor 8% gewijzigd door mindcrash op 25-12-2014 22:13 ]

[WinstonC]

Het bouwen van een eigen 'framework' is natuurlijk nooit iets wat je aan de klant factureert. In ieder geval, ik zou het nooit doen. En als ZZP'er, zoals ik, zijn deze dingen natuurlijk stukken makkelijker te handhaven dan wanneer je in een bedrijf werkt met meer dan één werknemer.

Het is een manier voor mij om gemakkelijk en relatief snel nieuwe websites te kunnen realiseren voor klanten. Wat betreft de security; zal het onveiliger zijn wanneer ik, net als in het begin, zonder ook maar enig designpattern te handhaven websites in elkaar knutsel? Dus HTML en PHP gecombineerd in één bestand bedoel ik dan. Ik denk zelf van niet.

[ Voor 3% gewijzigd door WinstonC op 25-12-2014 23:10 ]

[Barryvdh]

WinstonC schreef op donderdag 25 december 2014 @ 23:09:
Het bouwen van een eigen 'framework' is natuurlijk nooit iets wat je aan de klant factureert. In ieder geval, ik zou het nooit doen. En als ZZP'er, zoals ik, zijn deze dingen natuurlijk stukken makkelijker te handhaven dan wanneer je in een bedrijf werkt met meer dan één werknemer.

Het is een manier voor mij om gemakkelijk en relatief snel nieuwe websites te kunnen realiseren voor klanten. Wat betreft de security; zal het onveiliger zijn wanneer ik, net als in het begin, zonder ook maar enig designpattern te handhaven websites in elkaar knutsel? Dus HTML en PHP gecombineerd in één bestand bedoel ik dan. Ik denk zelf van niet.

nee, waarschijnlijk is dat inderdaad even onveilig Dat maakt het nog niet goed.

En tenzij het over hele simpele sites gaat, ben je ook als zzper beter af met een standaard framework.

[Sgreehder]

Opvallend dat je zelf probeert iets op te zetten om precies de redenen waarom je een framework zou gebruiken. ZF2 heeft bijvoorbeeld een skeleton application (https://github.com/zendframework/ZendSkeletonApplication) en de standard edition van Symfony is praktisch direct klaar voor gebruik. Voordelig, want frameworks zijn getest en bieden meestal wel alles wat je nodig hebt. Ook prettig voor de contuiniteit, want de volgende ontwikkelaar die aan de slag moet met jouw code hoeft zich alleen met de relevante delen bezig te houden.

[Ramon]

Ik vind het een beetje jammer dat iedereen komt met "gebruik een bestaand framework", dat is niet waar dit topic over gaat. Natuurlijk is een bestaand framework in veel gevallen beter, maar als ik naar mezelf kijk (ik heb ook zelf een MVC framework gemaakt toen ik net begon) helpt het zelf maken van een MVC framework enorm om de concepten van MVC onder de knie te krijgen.

Mensen moeten ook hun eigen fouten kunnen maken, anders leer je niets.

[ Voor 4% gewijzigd door Ramon op 26-12-2014 00:22 ]

[Ventieldopje]

Ik heb nooit lessen gehad en totaal geen ervaring met bestaande MVC-framework.
Wel heb ik er al heel veel theorie over gelezen.

Beter goed gejat dan slecht zelf bedacht... lees je zelf eerst eens in en ga eens ontwikkelen met Zend en Symfony/Laravel (2 hele bekende frameworks). Beide concepten zijn aardig anders maar allebei toch MVC en zo kom je misschien zelf ook op een idee om MVC te implementeren voor wat jij denkt dat fijn werkt. De opzet die je nu hebt staan doet mij gelijk denken aan code waar maar aan door gemodderd is, soms moet je het spulletje bij de kloten pakken en echt dingen structureel anders maken, waarom je dat geen verbetering vind is mij een raadsel.

[WinstonC]

Ventieldopje schreef op vrijdag 26 december 2014 @ 00:35:
[...]


Beter goed gejat dan slecht zelf bedacht... lees je zelf eerst eens in en ga eens ontwikkelen met Zend en Symfony/Laravel (2 hele bekende frameworks). Beide concepten zijn aardig anders maar allebei toch MVC en zo kom je misschien zelf ook op een idee om MVC te implementeren voor wat jij denkt dat fijn werkt. De opzet die je nu hebt staan doet mij gelijk denken aan code waar maar aan door gemodderd is, soms moet je het spulletje bij de kloten pakken en echt dingen structureel anders maken, waarom je dat geen verbetering vind is mij een raadsel.

Als hij zich verdiept in MVC door allerlei dingen erover te lezen op internet is dat toch hetzelfde als een bestaand framework uit te proberen? Het is net maar hoe praktisch of theoritisch je zelf bent ingesteld.

Zo is het MVC framework wat ik gemaakt heb en gebruik, grotendeels gebaseerd op het MVC framework van ASP.NET waar ik kennis mee heb mogen maken op mijn stage. En nogmaals: ja, ik kon misschien ook wel een bestaand framework gebruiken en misschien was dat inderdaad ook wel beter wat betreft bepaalde onderdelen, maar er zit ook een stukje 'zelluf' doen.

[Ventieldopje]

Ik zeg ook dat hij beide moet doen. Symfony en dergelijken zijn te complex om maar even mee te spelen zonder daarbij de nodige documentatie door te nemen. Ook best practices en hun uitleg 'waarom' zijn vaak interessant.

Zelf een MVC framework ontwikkelen voor productie vind ik binnen een klein team nog steeds erg gewaagd tenzij je als doel hebt dat MVC ook serieus te gaan ontwikkelen en daarbij dus in wil groeien. Voor in-house doeleinden is het vaak amper een verstandige keus.

Je kunt nog zo'n mooie toren bouwen maar als je hem bouwt op poep krijg je vroeg of laat problemen. Tenzij het poep met een vlaggetje is, dan geef ik je een kans.

[Cartman!]

Daarom denk ik dat Silex een heel mooi (micro)framework is, kan out of the box al veel, logisch opgezet en de documentatie is kort en bondig. Wil je daarna meer of uitgebreider dan kun je verder met Symfony 2, Silex is immers gebouwd puur op componenten van Symfony 2.

Een eigen framework gaat altijd onveilig(er) zijn dan de gevestigde orde en daarnaast ga je bij elke nieuwe requirement het wiel opnieuw uitvinden. Het is bijna 2015 en vrijwel de hele PHP community werkt met composer packages, waarom dan zo eigenwijs alles zelf willen doen? Zonde van je tijd.

[Sgreehder]

Ventieldopje schreef op zaterdag 27 december 2014 @ 02:44:
Ik zeg ook dat hij beide moet doen. Symfony en dergelijken zijn te complex om maar even mee te spelen zonder daarbij de nodige documentatie door te nemen. Ook best practices en hun uitleg 'waarom' zijn vaak interessant.

Dat valt wel mee toch? Ik bedoel, voor de meeste (basis-)taken zijn er redelijk kant-en-klare voorbeelden.

Interessanter wordt het als je eenmaal een ontwikkelde applicatie hebt. Je kan dan bij wijze van optimalisatie onderdelen van een bestaand framework uitschakelen cq. vervangen voor lichtere drop-ins. Dat kan alleen als redelijk ingelezen bent op het framework en de theorie erachter.

[Scr33x0r]

Tja, net als Barryvdh ben ik groot laravel fan! Ik ken de community een beetje en ze lopen erg voorop qua technieken, het toepassen van design patterns en concepten die al dan niet geleend zijn uit andere talen of een combinatie daarvan.

Een website die mij overigens erg geholpen heeft: http://www.phptherightway.com

Wat RobIII zegt is ook wel waar, een mappenstructuur is niet een design pattern.. En alleen MVC is niet meer voldoende tegenwoordig wat mij betreft.

Een aantal belangrijke dingen die ik mijn team altijd voorschotelde als ze bij ons begonnen:
- SOLID principles, waarvan ik de S (Single repsonsibility) eigenlijk het belangrijkste vind
- Repository pattern, denk aan een soort abstractie laag tussen je models en je ORM
- Domain Driven Design, splits je domain logic/business logic van je applicatie en zorg dat dit makkelijk te onderhouden is

En wat ik zou zeggen, kijk eens naar de filmpjes van Jeffrey Way op laracasts, dit is met name weer toegespitst op laravel, maar er zijn genoeg filmpjes die met name over de dingen als design patterns gaan.

De laatste jaren is PHP wat mij betreft een stuk volwassener geworden, steeds meer kennis/patterns/concepten die bijv. al even in JAVA leven worden gebruikt in PHP.

Inhoudelijk op je mappenstructuur zou ik zeggen, je split het nu eigenlijk per domein, ik zou het eerder op type splitsen, dus echt models, controllers en views splitsen.

Aan de naamgeving zou ik wat veranderen, denk sowieso aan PSR-4, maar meta.php zegt niks over de class die daarin staat. Wat doet het? Waarom niet MetaTagsController bijv.? Ik zou ook eens kijken naar de O van SOLID (https://laracasts.com/tags/principles), dit gaat om het open en closed principle. Je zegt nu dat dingen vanuit het begin zo zijn ontstaan omdat het eerst alleen verantwoordelijk was voor het vullen van je metatags? Als het meer dan alleen dat gaat doen gaat de S van SOLID al niet op, de meta class doet nu opeens meer dan alleen metatags vullen, hij handelt blijkbaar ook je post en gets af. Waarom heb je daarvoor niet een RequestController die je ook ergens in laadt?

Maar nogmaals, ik zou eens wat van die filmpjes gaan kijken, eens rond spelen met bijv. laravel of een ander framework. Ga eens werken met interfaces, dependency injection en IoC containers (http://stackoverflow.com/...-and-dependency-injection)

Ik hoop dat je er wat aan hebt? Misschien eens je source op github inschieten en wellicht zijn er een aantal mensen die je dan evt een beetje op weg willen helpen door wat pull requests in te schieten?

[Amanush]

Ik werkte samen met een andere Tweaker aan een bedrijf. Die andere Tweaker had zelf een Ruby framework gebouwd. Het hele framework was niet gebaseerd op het MVC-pattern, maar had wel een logische structuur, gebaseerd op "documenten".

Ik moest erg wennen aan het framework, en er was geen documentatie. Voor mij vormde dat een redelijk probleem. Het duurde mij twee weken het framework te leren kennen en onder de knie te krijgen.

Ondanks alles heb ik wel geleerd waarom mensen een custom framework bouwen. Deze keer werd het gedaan om performane-redenen. Zelf zou ik het niet doen, ik kies graag voor het bekendste framework mogelijk. Dat verkleint de kans dat andere programmeurs "het framework moeten leren". Ook is er dan al duidelijke documentatie van beschikbaar.

Laten we eerlijk zijn: een framework bouwen en documenteren kost veel tijd.. En tijd = geld!
Een bestaand framework is gewoon "goedkoper", en vaak ook "beter".

Maar: als je een framework bouwt, puur om meer over MVC te leren, of anders te leren denken, is het een grote aanrader!

[ Voor 17% gewijzigd door Amanush op 02-01-2015 13:21 ]

[Cartman!]

Als performance een reden is om een custom framework te maken dan denk ik dat je naar een andere taal moet kijken of naar andere soort optimalisaties (CDN, cache).

[Anoniem: 26306]

Amanush schreef op vrijdag 02 januari 2015 @ 13:18:

Maar: als je een framework bouwt, puur om meer over MVC te leren, of anders te leren denken, is het een grote aanrader!

Als je echt meer over MVC wilt leren, moet je een applicatie bouwen die een beetje state bewaart. Een webapplicatie is minder geschikt om echt goed te begrijpen hoe je MVC goed moet inzetten.

[Amanush]

Cartman! schreef op vrijdag 02 januari 2015 @ 13:53:
Als performance een reden is om een custom framework te maken dan denk ik dat je naar een andere taal moet kijken of naar andere soort optimalisaties (CDN, cache).

Veel PHP developers willen niet afstappen van PHP, hetzelfde voor Ruby, Python en C# developers.
Persoonlijk zou ik kijken naar een andere taal.

Anoniem: 26306 schreef op vrijdag 02 januari 2015 @ 14:22:
[...]

Als je echt meer over MVC wilt leren, moet je een applicatie bouwen die een beetje state bewaart. Een webapplicatie is minder geschikt om echt goed te begrijpen hoe je MVC goed moet inzetten.

Eens, maar een webdeveloper gaat geen app met UI maken - generalisatie, gaat om het idee -, gewoonweg om MVC te leren.

[ Voor 34% gewijzigd door Amanush op 02-01-2015 15:01 ]

[REDSD]

ik vind het een mooi initiatief dat je zelf een mvc probeert op te zetten.
Ik probeer zo nu en dan ook zelf dingen te bouwen om de problemen die kunnen ontstaan beter te begrijpen.

Als je al een lange tijd geen php hebt gedaan zou ik toch kiezen voor een simpel framework om de basis opzet te begrijpen voordat je iets zelf probeerd op te zetten.
Laravel en codeigniter zijn 2 makkelijke systemen waar je binnen een dag al iets opgezet kan hebben

Als je dat eenmaal door hebt merk je ook wat de sterke en zwakke punten zijn van zulke systemen.

De discussie over het gebruik van een andere taal omdat die zich beter lenen, vind ik onzin, een goede ontwikkelaar maakt goede oplossingen ongeacht de taal. Het feit dat php niet gecompiled wordt is soms een voordeel en soms niet. Het heeft mij nooit problemen bezogt. De grootste websites ter wereld draaien voor een deel op php.

Ik snap dat je niet overnieuw wilt beginnen, maar ik kan je aanraden om laravel of codeigniter op te pakken, vooral laravel 4 is een mooi systeem die de overstap naar symfony 2 een stuk makkelijker kan maken.
Als dat lukt zal je vanzelf php beter en beter begrijpen.

Ontwikkel een keer een module voor een bestaand systeem, dat zijn de manieren om dingen te leren en nog iets nuttigs toe te voegen.

[Cartman!]

REDSD schreef op vrijdag 02 januari 2015 @ 18:56:
De discussie over het gebruik van een andere taal omdat die zich beter lenen, vind ik onzin, een goede ontwikkelaar maakt goede oplossingen ongeacht de taal. Het feit dat php niet gecompiled wordt is soms een voordeel en soms niet. Het heeft mij nooit problemen bezogt. De grootste websites ter wereld draaien voor een deel op php.

Een goede ontwikkelaar maakt een taal niet ineens heel veel keer sneller want de beperking zit dan in de taal en niet in het framework. Tweakers heeft de pricewatch ook niet gemaakt in PHP omdat de performance gewoon niet goed genoeg is bijvoorbeeld. Maakt het PHP slecht? Nee. Is PHP het meest geschikt? Nee.

De delen die grote sites vaak draaien op PHP is meestal niet het onderdeel wat enorm moet performen met honderden (of vele malen meer!) messages per seconde. Juist grote sites maken goed gebruik van een taal voor bepaalde delen van de site.

[REDSD]

De keuze voor een taal is niet alleen op basis van de snelheid, tuurlijk Java, .Net, Ruby, Python kunnen allemaal sneller zijn in de juiste handen. Bij de meeste websites is de programmeer taal trouwens vaak niet de bottelneck, maar vaak de data die er achter zit. Databases, hun opbouw en content dingen die vaak langer duren dan de code om op te halen of te verwerken.

Goede ontwikkelplatformen zijn per geval anders, de ene moet snel kunnen deployen en inspelen op veranderingen, de andere hecht waarde aan een sterke standaard waar fouten tot het minimum behoren.
Ik denk wel dat veel bedrijven ook kijken naar hun inhuis ontwikkelteam of waar ze makkelijk mensen van kunnen krijgen.

Pfff zoveel factoren die een taal en opzet bepalen, voor je salaris of uitdaging kan het uitmaken, maar ik denk dat goede ontwikkelaars atm nog altijd goed terecht kunnen komen, ongeacht welke taal.