Door
Rob D
op 09-12-2016 16:02
gewijzigd op 09-12-2016 16:07
3.772 views
Ik heb een tijd geleden een framework gebouwd en wil deze gaan upgraden naar een hogere PHP versie en modernere methodes.
De routing methodiek die ik nu gebruik is het volgende:
• de uri bestaat uit: http://domein.com/controller/method/param1/...
• lees de URI uit $_SERVER['REQUEST_URI']
• explode de URI in parts
• construeer het include path mbv de parts
• als de controller bestaat instantieer deze
• als de method bestaat roep deze aan met de parameters als argumenten
• bestaat de controller of method niet: 404.php
<?php
$controllerFile = "public/" . $app . "/controllers/" . $controllerPrefix . "Controller.class.php";
if (file_exists($controllerFile)) {
require_once $controllerFile;
} else {
throw new Exception('Controller file does not exist: ' . $controllerFile);
}
$class = ucfirst($controllerPrefix) . 'Controller';
if (class_exists($class)) {
$controller = new $class();
$controller->initLocale($country, $language);
if (isset($urlParam) && !empty($urlParam)){
$controller->index($controllerPrefix, $action, $urlParam);
} else {
$controller->index($controllerPrefix, $action);
}
} else {
throw new Exception("Controller class does not exist") . '!';
}
?>
Ik constateer echter dat alle bekendere frameworks, zoals Symphony, Laravel, Slim, etc een routing systeem gebruiken gebaseerd op, wat ik maar noem, een ‘hardcoded’ manier zoals in Laravel:
Elk framework heeft natuurlijk zijn eigen coding style voor deze functionaliteit.
Hierdoor moet iedere route gecodeerd worden; heb ik 50 controller (niet abnormaal bij ons) moet ik 50x een get of post (of soms beide) regels coderen en dat elke keer als er een nieuwe controller wordt toegevoerd of verwijderd. Met mijn methode hoef ik dat niet en is dus veel generieker.
Mijn vraag daarom: waarom geven de framework toch voorkeur aan het uitschrijven van de uri? Anders gezegd: wat zijn de voor- en nadelen van beide methoden.
Misschien moet je beginnen bij het stipje ver weg aan de horizon: wat denk je dat er allemaal is opgelost wanneer je alles hebt herschreven naar een framework van derden?
Met wat simpele basisprincipes kom je heel ver, ook zonder PHP-framework. Refactoring begint meestal met het afgaan op de stank van code smell. Gebruik je op twee plaatsen dezelfde drie SLOCs? Dan begint het te ruiken naar te vaak gedragen sokken. Heb je een methode met meer dan drie parameters? Dan doet die te veel en ruik je dat aan de zweetlucht.
Voordat je besluit welk (ander) PHP-framework veel beter is, moet je eigenlijk eerst nagaan hoe slecht je eigen framework nu is. Ik kan je het boek Refactoring van Martin Fowler aanbevelen.
Ik zeg niet dat je zonder framework niet modulair of niet met versiebeheer kunt werken. Ik vroeg me enkel af of jullie dat wel deden. Hoop niet dat je me het kwalijk neemt dat ik geen enkel idee heb hoe jullie organisatie werkt :-)
Als je kunt antwoorden met Ja we hebben versiebeheer, migratie en verschillende onderdelen (blokken/bundles whatever) goed op de rails dan zal ik de laatste zijn die zegt dat je nu alle bestaande code moet gaan herschrijven om deze geschikt te maken voor welk framework dan ook.
En natuurlijk een eigen framework/systeem kan ook goed werken maar ik blijf wel van mening dat je tijd en dus geld moet investeren in het ontwikkelen maar ook in het onderhouden van een dergelijk systeem. Zo zijn er met de komst van PHP7 weer een aantal functies komen te vervallen. Maakte je daar gebruik van dan zul je dat vroeg of laat (ik denk vroeg) moeten wijzigen.
>> Nog even ter aanvulling: onze applicatie, met alle business rules, validaties, security issues, bestaat voor een zeer groot deel uit php code, webpaginas vol met javascript, Oracle stored procedures. Geen enkel framework levert mij die volledige functionaliteit, je zal die toch zelf moeten bouwen.
Dat klopt. Maar er zijn wel frameworks die je een goede structuur aanbieden waar je al deze onderdelen in kunt onderbrengen en nog eens kunt hergebruiken ook.
Ik weet wel dat met een Framework (mits je deze onder de knie hebt), het ontwikkelen stukken sneller gaat. Het kost alleen even tijd om je te verdiepen in een framework wat zich uiteindelijk terugbetaald in
- rapid development
- code reuse
- template engine (html/php)
- handige ingebouwde functies zoals:
- snel databases en tabellen aanmaken
- queries schrijven
- onderlinge relaties met tabellen.
- onderscheidt tussen dev en live
- meestal een handige debugger
- etc...
Zo kan ik het lijstje nog wel even blijven aanvullen :)
Maar ik snap dat het lastig qua tijd en groei om alles te moeten overzetten naar een framework.
Ik begrijp en ondersteun je punt over het gebruik van framework. Wat ik duidelijk wil maken is dat we wel een framework hebben. Een framework dat ik samen met een collega ruim 10 jaar geleden heb gebouwd.
Dat is wat ik ook aangaf in de 1e regel van mijn oorspronkelijke vraag.
Dit 'framework' is een MVC gebaseerd systeem, met routing, security modules, database abstractie (adodb), een mailer syteem. Geen template systeem voor de views, maar een page/form generatie systeem gebaseerd op phphtmllib, etc., etc.
Misschien is het in het verhaal belangrijk te weten dat we jaren geleden uit een volledige Oracle omgeving kwamen en onze programmeurs evenveel weten als de doorsnee DBA. Databases en queries maken zijn onze dagelijks brood. Wij maken geen websites, maar een complex transactie systeem, met honderden views en tabellen.
Dit systeem is echter verouderd en uit zijn voegen gegroeid maar in principe kan het alles en voldoet nog ruim aan de eisen van de markt. Ik heb reeds een nieuw framework gebouwd, maar eenvoudiger, meer op moderne principes, om onze apps 'leaner and meaner' te maken. Daarom kijk ik nu naar wat er in de php wereld is vernieuwd.
Mijn keus is dus: wat ga ik doen, ons nieuwere framework complient maken met de laatste stand van zaken in de php wereld (wat mijn programmeurs hart wil) of het adapteren van een bestaand framework dat zich reeds heeft bewezen in de markt (wat mijn managers hart wil).
Ons eigen framework voldoet en heeft zich bewezen; wij weten hoe we een framework moeten maken; zodra de basis er staat wordt die over de jaren nauwelijks nog gewijzigd. De functionele software (forms, javascript, db tables, business rules, proces flow, calculaties, gegenereerde pdf's en excel docs, (rest/soap) interfacing, etc) wordt bij ons wel dagelijks voor de ene of andere klant onder handen genomen. Dat levert een framework niet, maar is de eigenlijk core van elk systeem.
Vandaar dat ik mij niet zo druk maak over wat een framework voor ons mogelijk sneller kan doen; daar zit onze tijd niet in.
Waar het mij om gaat is om onze manier van bouwen mee te laten groeien met wat de markt doet. Als er iets beters, makkelijk of sneller is wil ik dat adapteren (ook als dat een nieuw framework betekent). Ik merk zowiezo al dat ik weer nieuwe dingen kan leren en ben daarom ook zeer blij met jullie input.
[size=xsmall]Toevoeging op 13/12/2016 22:32:28:[/size]
Thomas, ik zat te denken om een klein project te beginnen met Slim en die aan te vullen met de modules die ik nodig heb. Zo leer ik de pro's en cons stap voor stap. Maar misschien is het beter om meteen te beginnen aan een framework zoals Laravel of Symphony ...
[size=xsmall]Toevoeging op 14/12/2016 09:53:40:[/size]
Thomas, om even terug te komen op je opmerking over de empty() functie. Volgens mij test deze functie niet of de variabele bestaat.
Als bijv. $tstVar niet bestaat zal empty($tstVar) == true geven, terwijl isset($tstVar) == false geeft.
empty() geeft in dat geval geen melding, waar isset() dat wel doet.
Thomas doelde op de vaak gebruikte constructie if (isset($var) && !empty($var)) voor "als de variabele bestaat en de variabele niet leeg is". Dat zijn twee of drie logische evaluaties waar je met één evaluatie kunt volstaan, want:
Mijn keus is dus: wat ga ik doen, ons nieuwere framework complient maken met de laatste stand van zaken in de php wereld (wat mijn programmeurs hart wil) of het adapteren van een bestaand framework dat zich reeds heeft bewezen in de markt (wat mijn managers hart wil).
Een programmeur: wil een gedegen, flexibel en stabiel systeem
Een manager: wil zo snel mogelijk een werkende oplossing
Kiezen voor een bestaand systeem is leuk, maar de leercurve van zo'n systeem is bijzonder groot. Weet je eindelijk na een jaar hoe alles een beetje werkt, komt er een nieuwe versie en werkt alles ineens anders. Of ... na 2 jaar besluiten de makers ineens om het systeem niet verder door te ontwikkelen. En dan?
Als ik jou zo hoor dan gaat het bij jullie om je core business. Ik zou me daarbij nooit afhankelijk maken van een extern framework. Wat zeg je straks als er iets niet werkt (vanwege een lek)? Geef je dan dat externe framework de schuld? In jouw geval zou ik dus altijd ervoor kiezen om je eigen framework te maken. Op de lange termijn is dat de veiligere oplossing.
Deze hele discussie geeft al aan dat een keuze voor een externe (of interne) systeem geen vanzelfsprekendheid is.
Als ik naar bijv. het routing systeem kijk van Slim of Laravel dan zijn die superflexibel, maar die flexibiliteit kan ook leiden naar onduidelijkheid. De ontwikkelaars willen een strakke, heldere methodiek, dat altijd werkt als je je maar aan de regels houdt.
De keuze is enerzijds lastig omdat ik niet voor Laravel wil kiezen en er dan achter komen dat ik eigenlijk Symphony nodig had. We hebben geen tijd om al die frameworks uit te proberen.
En van de andere kant heb ik een luxe positie, omdat we een systeem hebben dat werkt. Het huidige systeem is ontstaan door af te kijken en te nemen wat voor ons werkt, waarom zouden we dat dan nu ook niet doen.
Hoe dan ook is het een feit dat in de moderne frameworks veel best practices zitten die waard zijn om te gebruiken. Ook moet je rekening houden met het feit dat huidige frameworks veel modules bevatten die gemakkelijk zijn over te nemen of waar alternatieven voor bestaan.
Kortom, ik hoop door middel van een paar kleinere projectjes met verschillende frameworks een gevoel te krijgen welke kant we op gaan.
