Inhoud
Vraag me welk raamwerk ik moet gebruiken en ik zal waarschijnlijk een chagrijnig oud vrouwmoment hebben en je vertellen dat alle raamwerken zo slecht zijn als elkaar. Dat wil niet zeggen dat ze allemaal slecht zijn, maar in PHP hebben we een onvoorstelbaar groot aantal frameworks (meestal aangehaald als N + 1, waarbij N het aantal PHP-ontwikkelaars in de wereld is), en ze waren waarschijnlijk allemaal logisch aan de persoon die ze heeft uitgevonden.
Een keuze hebben uit frameworks is waarschijnlijk beter dan proberen om slechts één framework te gebruiken, ongeacht wat u precies probeerde te bouwen, omdat het de ’beste’ is (in welke mate dan ook van ’beste’). Deze selectie van raamwerkaanbiedingen betekent dat u iets kunt kiezen dat aan de behoeften van het project voldoet en dat het zelfs kan worden gedocumenteerd. Frameworks op elk platform zijn er echt om structuur, herbruikbare modules en bibliotheken te bieden en over het algemeen alle saaie en repetitieve taken te vermijden die te maken hebben met het steeds opnieuw bouwen van dezelfde functionaliteit. Bij het bouwen van CMS'en moet bijvoorbeeld iets formuliervelden voor mij verwerken en valideren; als ik aan mijn lot overgelaten word, mis ik misschien iets belangrijks en doe ik veel liever de elementen van elk project die dat zijn anders, in plaats van degene die elke keer hetzelfde zijn!
Full-stack frameworks
Full-stack frameworks, zoals Zend Framework, kunnen een mooie start zijn voor een ontwikkelaar zonder veel architectuurervaring. Het geeft een goede structuur om een nieuwe applicatie aan op te hangen, en er is een goed ’ecosysteem’ omheen - veel boeken, tutorials en ook wat redelijke documentatie. Als u een grote applicatie probeert te bouwen die door veel mensen zal worden onderhouden, dan is een populair, uitgebreid framework waarschijnlijk een goede keuze, aangezien het behoorlijk wat structuur zal dicteren en goed bekend en begrepen zal zijn.
Structuur hebben om te helpen bij scheiding is altijd goed; vroeg in mijn carrière werkte ik met sommigen heel junior ontwikkelaars en probeerden ze het MVC-patroon (Model View Controller) aan te leren, dat toen relatief nieuw was. We hebben de beslissing genomen om Smarty in de weergavelaag te gebruiken; gedeeltelijk zodat de ontwerpers gemakkelijker met de sjablonen konden werken, en gedeeltelijk zodat wanneer iemand naar mijn bureau kwam en zei "hoe doe ik X met Smarty?" Ik zou kunnen zeggen "doe X niet in het uitzicht!" (negen van de tien keer, dat was het antwoord). Het hebben van frameworks helpt ons om dezelfde scheiding te vinden in andere delen van onze applicatie. Velen van hen ondersteunen integratie met een sjabloonlaag zoals Smarty, of mijn nieuwe favoriet, Twig, dus je kunt die tools met je meenemen, welk framework je ook kiest.
De last verlichten
Er zijn veel lichtere frameworks dan Zend Framework, ik werk bijvoorbeeld behoorlijk met CodeIgniter. Is het zo uitgebreid en robuust als Zend Framework? Nee, dat is het niet. Maar als hulpframework om snel een applicatie te kunnen bouwen, is het handig. Over het algemeen kunnen frameworks met minder 'helper'-functionaliteit gemakkelijker uw weg vinden, omdat het veel duidelijker is hoe de onderdelen bij elkaar passen. In een onbekend kader (voor mij is dat vrijwel alles), zijn het de automagische stukjes die het moeilijk maken om mee te werken en fouten op te sporen.
Dat gevoel "verdwaald te zijn in een nieuw kader" is onvermijdelijk en uiterst frustrerend; zelfs een ervaren ontwikkelaar voelt zich een nieuweling als ze niet weten hoe iets werkt. Als je echt pech hebt, heb je een raamwerk gekozen waarvan het IRC-kanaal je zal vertellen dat je ook een idioot bent! Het is deze zeer negatieve eerste ervaring die veel mensen ervan weerhoudt een nieuw raamwerk te gebruiken of er überhaupt een te adopteren, en maar heel weinig raamwerken zijn goed in het helpen van nieuwe gebruikers over die eerste hindernis.
In PHP hebben we ook enkele frameworks die niet echt frameworks zijn zoals ik het woord gewoonlijk gebruik. We hebben een aantal mooie component-frameworks; collecties van bibliotheken die zijn ontworpen om naar believen te worden gebruikt en om mooi samen te spelen, zoals Zeta Components (voorheen eZ Components) en Symfony Components (heb je hun site gezien? Ze winnen de prijs voor het beste artwork!). Het beste en meest onderkende hiervan is natuurlijk het eigen PEAR- en PECL-aanbod van PHP - op de een of andere manier worden deze vergeten in deze dappere nieuwe wereld van frameworks.
Microframeworks
Microframeworks is een opkomende trend in PHP; dit zijn superlichte aanbiedingen die je gewoon helpen om dingen sneller aan elkaar te lijmen. Een goed voorbeeld is Slim, dat erg snel en eenvoudig te gebruiken is, en RESTful-concepten begrijpt. Het is gebaseerd op het idee van ‘routes’, dit zijn URL-patronen. U registreert een route en geeft een callback die moet worden aangeroepen wanneer die URL wordt opgevraagd.
De meeste PHP-ontwikkelaars gebruiken een framework en houden zich eraan, of ze gebruiken er een op het werk en een ander voor hun hobby of open source-projecten. Er is weinig consensus over het "beste" raamwerk om te gebruiken, dus iedereen houdt gewoon vast aan wat ze weten en het resultaat is een parallelle ontwikkeling van enorme aantallen raamwerken! Ik vind het heerlijk om een selectie te hebben om uit te kiezen, maar had ik al gezegd dat ze allemaal net zo slecht zijn als elkaar?
Als u Zend Framework kent, beschrijft u uzelf uiteindelijk als een Zend Framework-ontwikkelaar; je zou pas in een ander framework schrijven als je de kans had gehad om het onder de knie te krijgen, en je herinnert je waarschijnlijk niet veel van de onbewerkte PHP-functies voor dingen als je ze niet vaak gebruikt. Het idee dat we framework-specifieke ontwikkelaars zijn geworden, die alleen op abstractielagen werken, is een beetje vreemd voor PHP. Dit is tenslotte de taal "om het webprobleem op te lossen". Het is geschreven in C en is op zichzelf een snelle, lichte taal ... vooropgesteld dat je niet wacht tot er een groot framework-bootstrap-proces wordt uitgevoerd! Uit deze context kwam het MicroPHP-manifest voort, geschreven door een man die we Funkatron noemen (hoewel zijn naam eigenlijk Ed Finkler is). Het is een reeks uitspraken die zeggen dat het oké is om een aantal interoperabele kleine modules te bouwen, dat groter niet beter is, en dat het leven echt te kort is voor Java - zelfs als het in PHP is geschreven.
