Routing methoden

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Senior Cobol Applicatieontwikkelaar

Bedrijfsomschrijving De IV- organisatie van de Belastingdienst is verantwoordelijk voor en verzorgt de ICT- voorzieningen. Het merendeel van de applicaties wordt op dit moment door de IV- organisatie zelf ontwikkeld, onderhouden en beheerd in het eigen data center. Naast de zorg voor continuïteit op de massale heffing- en inningsprocessen die plaatsvinden binnen een degelijke, stabiele omgeving, wordt er tevens volop gewerkt aan modernisering van het IV- landschap. Dit gebeurt deels intern door gebruik te maken van de expertise die intern aanwezig is, maar ook door het aantrekken van (kant-en-klaar) oplossingen en expertise uit de markt. Functieomschrijving In de applicatie ETM

Bekijk vacature »

Java Developer

Functieomschrijving Are you an experienced Java Developer who wants to be challenged? Then this is your job! As a Java Developer, you are co-responsible for building custom applications within our extensive IT landscape. Development takes place on both the back-end side (Spring/JEE). Together with the IT department, you are responsible for the daily adjustments and expansions of our IT systems. In addition, you will work in small scrum teams using the Agile methodologies. Besides the realization of our in-house systems, you are responsible for the roll-out of the application (version) as well as the operational support after going live. Team

Bekijk vacature »

Laravel PHP developer in een jong team

Bedrijfsomschrijving Als je op zoek bent naar een werkplek waar plezier en uitdaging hand in hand gaan, dan is dit bedrijf de juiste keuze voor jou. Hier kun je werken aan uitdagende projecten en krijg je als developer veel verantwoordelijkheid. Het bedrijf waardeert kwaliteit boven kwantiteit en richt zich op het ontwikkelen van hoogwaardige applicaties en websites waar klanten enthousiast over zijn. Dit bedrijf is vooruitstrevend en streeft naar het leveren van de best mogelijke resultaten voor hun klanten. Als medior PHP ontwikkelaar met 3 jaar ervaring ben jij de persoon die we zoeken. Je krijgt hier de kans om

Bekijk vacature »

Senior Fullstack developer wanted! (C#, Java, Angu

Functie Under the guidance of 3 account managers, one of whom will be your point of contact within your expertise, you will start working for various clients. He or she will help you find a suitable and challenging assignment. Naturally, they will take your situation, experience and (technical) ambitions into account. The assignments last one to two years on average. This allows you to really commit to a project and make an impact as a consultant. Besides the assignment, you will regularly meet your colleagues from the IT department to share knowledge or discuss new trends, for example. Master classes

Bekijk vacature »

Medior/Senior Software Developers gezocht in de Ra

Functie Op dit moment staan er posities open voor de volgende functies: Front-end, Back-End & Fullstack software developer. Als Front-End software developer werk je met JavaScript en de bijbehorende technologieën zoals TypeScript, Angular, React, Vue en Svelte. Als Back-End software developer ben je bezig in NodeJS en doe je dit met behulp van AWS, NoSQL, REST en GraphQL. Je krijgt leuke en uitdagende opdrachten met een gemiddelde duur van anderhalf jaar. Hier werk je in een team met andere IT’ers aan het ontwikkelen en verbeteren van software. Je wordt begeleid door een accountmanager die fungeert als jouw aanspreekpunt. Het team

Bekijk vacature »

C# .NET Developer

Dit ga je doen Ontwikkelen van de Back-end in .NET6 / C# en WebAPI (Focus);) Ontwikkelen van de Front-End in Nodje.js en Angular (secundair); Ontwikkelen in Blazor; Opstellen van een technisch ontwerp; Testen, documenteren en implementeren van de nieuwe applicatie; Verzorgen van de nazorg, na de implementatie. Hier ga je werken Binnen deze organisatie werken duizenden mensen binnen allerlei verschillende disciplines. Tevens hebben zij veel specialiteiten in huis, waaronder ook .Net Developers. Ter uitbreiding van een nieuw team en ter ondersteuning van het project zijn ze opzoek naar een nieuwe collega voor het team. Als C#.NET Developer zal jij je

Bekijk vacature »

Lead Front-end developer

Functie Hun huidige applicatie worden ontwikkeld in o.a. React, Redux, TypeScript. Ze werken graag met de nieuwste technieken en tooling en zoeken ook developers die hier proactief op zoek naar gaan. Als senior/lead developer ben je een kartrekker in het team. Naast het meedenken over bijvoorbeeld de architectuur of toepassing van nieuwe technieken krijg je ook veel tijd om de meer junior (front-end) developers te begeleiden. Zo kun je bijvoorbeeld 1 dag in de week met 2 collega’s bezig zijn om samen met hen te kijken naar hun ontwikkeling, doelstellingen en uiteraard de gewenste begeleiding hierin. Hiernaast sta je als

Bekijk vacature »

Junior .NET developer

Functie Jij hebt natuurlijk net jouw Bachelor op zak en gaat nu voor het eerst aan de slag bij een werkgever als junior .NET ontwikkelaar. Waarschijnlijk lijkt het jou spannend om ineens aan de slag te gaan bij klanten in de consultancy. Maak je niet druk, jij komt hier terecht in een warm bad en wordt totaal niet in het diepe gegooid. Zodra jij hier begint wordt jij gekoppeld aan een persoonlijke manager met een persoonlijk ontwikkelplan. Jij krijgt een scala aan trainingen, denk aan trainingen ten behoeve van het opdoen van zelf kennis en gedragscompetenties, maar ook trainingen voor

Bekijk vacature »

Back-end Developer

Functieomschrijving Heb jij kort geleden je HBO ICT Informatica diploma in ontvangst mogen nemen? Of heb je een aantal jaar ervaring als Software Developer en ben je klaar voor een nieuw hoofdstuk in jouw carrière? Voor een gewaardeerde werkgever in de regio van Goirle zijn wij op zoek naar een junior/medior Back-end Developer met affiniteit met MS Acess. Samen met een vooruitstrevend team ben je verantwoordelijk voor het ontwikkelen van maatwerk software voor hun klanten. Je hebt kennis of ervaring van SQL en affiniteit met MS Acess. Je bent klantvriendelijk en flexibel ingesteld en vindt het leuk om klanten te

Bekijk vacature »

.NET Developer Shared Driving

Bedrijfsomschrijving Onze klant richt zich op het toegankelijker maken van steden, een fantastisch mooi streven. Hoe ze dat doen? Met eigen ontwikkelde software, waarmee vervoersmiddelen gedeeld kunnen worden. Deze inspirerende werkgever maakt een maatschappelijke impact en dat doen ze nu al zo'n 25 jaar! Het bedrijf is gevestigd in het centrum van Rotterdam en kent ongeveer zo'n 90 medewerkers. Het personeel is lekker gewoon gebleven! Iedereen kleedt zich zoals hij of zij dat zou willen en de sfeer is er erg fijn. Een leuke werkgever om voor te werken, en bovendien zijn er voor jou als Software Developer veel mooie

Bekijk vacature »

.NET developer

Functie Als .NET developer start jij in een development team met één Senior .NET developer en één junior .NET developer. Als team zijn jullie verantwoordelijk voor het schrijven van software voor onze toonaangevende Automatiseringssystemen. Jij gaat aan de slag met de onderhoud van de kernsoftware, ondersteund de software van derden door het gebruik van onze webservices en als team zijn jullie verantwoordelijk voor het ontwikkelen van onze backend oplossingen. Wij maken op dit moment veel gebruik van .NET met ASP.NET. Komend kwartaal gaan wij wel gedeeltelijk overstappen naar .NET Core. Verder werken wij ook met SOAP, REST, JSON, HTML5, CSS3

Bekijk vacature »

Full Stack Software Developer C#.NET

Functieomschrijving Wij zijn op zoek naar een gepassioneerde Full Stack C#.NET Software Developer. Als Software Developer ben je verantwoordelijk voor het ontwikkelen van webapplicaties, apps en dashboards voor de eigen IOT-oplossingen. Je werkt samen met andere ontwikkelaars en engineers om de sensoren in machines uit te lezen en deze data om te zetten in management informatie voor jullie klanten. Taken en verantwoordelijkheden: Ontwikkelen en onderhouden van webapplicaties, apps en dashboards voor de eigen IOT-oplossingen. Testen en valideren van de ontwikkelde software. Actief deelnemen aan code reviews en bijdragen aan het verbeteren van de kwaliteit van de software. Je gaat aan

Bekijk vacature »

.net developer

Hoi! Wij zijn auto.nl en wij verkopen auto's online. je bestelt bij ons een auto net zo makkelijk als een spijkerbroek. En bevalt ie niet? Dan stuur je 'm gewoon weer terug. En dat we dat goed doen bewijst onze hoge klanttevredenheid van een 9,3. Nu maken we de volgende stap bij auto.nl. We starten met fysieke winkels. Online zoeken, offline bekijken. Maar nog altijd, geen gedoe! Gewoon eerlijk, transparant en zonder zorgen een auto kopen.. Maar om dat waar te blijven maken en nóg beter te worden, zoeken we uitbreiding van ons development team. Wat ga je precies doen?

Bekijk vacature »

Starter/junior Magento developer gezocht!

Functie Je komt te werken in een zelfsturend team waarin vertrouwen voorop staat en inbreng en ideeën worden gewaardeerd. Ook staat innovatie centraal. Ze bieden jou de mogelijkheid om jezelf door te ontwikkelen. Denk hierbij aan cursussen en een persoonlijk ontwikkelplan. Je komt terecht in het team van momenteel 4 (ervaren) collega’s en zal meewerken aan de doorontwikkeling en nieuwbouw van de Magento platformen van meerdere opdrachtgevers volgens Agile/Scrum. Denk hierbij aan nieuwe functionaliteiten, UX en koppelingen met verschillende back-end systemen. Als starter/junior developer zul je direct begeleid worden door een senior uit het team. Het is van belang dat

Bekijk vacature »

Full stack Javascript ontwikkelaar

Functie Benieuwd hoe jouw dag eruit ziet? Je komt binnen rond een uur of 10 en dat start je met de morning call. Dit doen we vanaf het hoofdkantoor of op het lab, ligt eraan welk project je mee bezig bent. Na de call en het verdelen van de tickets ga je met je team aan de slag. Rond een uur of 12 is er een goede lunch en ga je smiddags weer lekker door met je werk. De ene keer maak jij een game voor een groot merk om de interactie tussen product en eindgebruiker te vergroten. De andere

Bekijk vacature »
Rob D

Rob D

09/12/2016 16:02:55
Quote Anchor link
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

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
<?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:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
<?php
Route::get('/', function(){}
Route::post('foo/bar', function(){}
Route::get('user/{id}', function($id){}
?>


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.

Ward:
Graag voortaan bij code de [code][/code]-tags gebruiken.
Hier kun je meer lezen over de mogelijke opmaakcodes.
Alvast bedankt!
Gewijzigd op 09/12/2016 16:07:56 door Ward van der Put
 
PHP hulp

PHP hulp

30/09/2023 06:00:49
 
Thomas van den Heuvel

Thomas van den Heuvel

09/12/2016 16:17:45
Quote Anchor link
Enkele notities:

file_exists() is i.i.g. een dure operatie. Wanneer je gebruik maakt van een autoloader dan heb je genoeg aan enkel een controle met class_exists().

Daarnaast lijkt mij isset($urlParam) && !empty($urlParam) nogal dubbelop, enkel !empty($urlParam) is genoeg, empty() heeft een isset() "ingebakken" controleert ook op het (niet) bestaan van de variabele.
Gewijzigd op 09/12/2016 16:18:58 door Thomas van den Heuvel
 
Ward van der Put
Moderator

Ward van der Put

09/12/2016 16:21:09
Quote Anchor link
Rob D op 09/12/2016 16:02:55:
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.

Om bij het einde te beginnen: dat doen ze om expliciet te maken dat route /a/b/ onder verantwoordelijkheid valt van controller X en geen enkele andere controller. Daarnaast kun je dan ook nog route /c/d/ aan controller X hangen én controller X vervangen door controller Y, zonder de routes te veranderen.

In jouw oplossing kan dat niet en zijn die beslissingen allemaal impliciet én hard-coded. Als je bijvoorbeeld een route wilt wijzigen, moet je de naam van de controller wijzigen en daarmee vervolgens ook nog de bestandsnaam van het bestand waarin die controller is opgeslagen. Dat soort trapsgewijze, in de logica van de code verborgen afhankelijkheden moet je zoveel mogelijk beperken.
 
Rob D

Rob D

09/12/2016 16:32:06
Quote Anchor link
Dank je voor jullie input; ik sta voor de keuze om met een bestaand framework te gaan werken of mijn eigen
framework te verbeteren. Veel code is jaren geleden gemaakt en afgekeken van voorbeelden inclusief de fouten :(. Daarom neig ik naar een bestaand framework waar slimmere mensen dan ik aan gewerkt hebben, maar ik wil de code natuurlijk wel begrijpen.
 
Thomas van den Heuvel

Thomas van den Heuvel

09/12/2016 16:40:37
Quote Anchor link
Los daarvan (laatste alinea reactie @Ward) ben je niet vrij in de naamgeving van je URLs; je zit vast aan het <controller>/<method>[/<whatever>] stramien. Je kunt je site dan niet hiërarchisch indelen op URLs wat wel eens handig kan zijn.

Al ben ik niet zo weg van al dat soort expliciete mappings ontkoppel je je URLs wel van code.
 
Frank Nietbelangrijk

Frank Nietbelangrijk

09/12/2016 21:37:19
Quote Anchor link
Rob D op 09/12/2016 16:32:06:
Dank je voor jullie input; ik sta voor de keuze om met een bestaand framework te gaan werken of mijn eigen
framework te verbeteren. Veel code is jaren geleden gemaakt en afgekeken van voorbeelden inclusief de fouten :(. Daarom neig ik naar een bestaand framework waar slimmere mensen dan ik aan gewerkt hebben, maar ik wil de code natuurlijk wel begrijpen.


Dat is nou precies het probleem. In plaats van bezig te zijn met het bouwen van een website zonder onder de motorkap te hoeven duiken ben je bezig met het ontwikkelen van een framework. Je kunt als individu niet alles zelf ontwikkelen of een klus komt nooit af.
Mijn inziens is het super belangrijk om voor de juiste tools te kiezen én te zorgen dat je hier snel in thuis raakt. Dat kan met wat video tuts, een boek of een heuse cursus. Dit is een kleine investering maar als je naar de uren kijkt heb je dat er zo uit.
 
Rob D

Rob D

12/12/2016 09:20:15
Quote Anchor link
Ik ben het met Frank maar deels mee eens.
Ik heb jullie misschien op heb verkeerde been gezet door met mijn vraag de indruk te wekken dat ik pas kort kom kijken in het PHP wereldje. Ik werk echter al zo'n 15 jaar met o.a. dit taaltje. Wij onderhouden al zo'n 10 jaar een framework dat wij gebruiken voor onze applicaties.
Ons framework wordt ingezet voor voor grote bedrijven wereldwijd. We praten hier niet over een website, maar over meerdere systemen met meerdere gigabytes aan code, gekoppeld aan een Oracle db met een paar honderd tabellen en een paar honderdduizende records.

Ik heb een aantal jaren geleden gekeken naar de bestaande frameworks, maar die konden toen niet de flexibiliteit leveren die wij nodig hadden en hebben. Natuurlijk blijf ik de ontwikkelingen met belangstelling volgen en ben ik geintesseerd in de methoden en technieken die gebruikt worden. Zeker als deze afwijken van methoden die wij (al jaren met succes) gebruiken.

Mijn punt:
Ja, er sluipen fouten in de code, maar die kan je in frameworks ook tegenkomen
Ja, een framework kan je helpen, maar kan je ook tegenwerken en is niet altijd zaligmakend
Ja, een framework kan je op ideeen brengen en daar kan je van profiteren
En ja, een framework kan zich over de jaren verder ontwikkelen zodat het wel een oplossing word.
Maar zelfbouw of gebruik maken van een bestaand framework zal altijd afhangen van de complexiteit, flexibiliteit en dynamiek die de markt vraagt.
 
Frank Nietbelangrijk

Frank Nietbelangrijk

12/12/2016 10:27:53
Quote Anchor link
Ik kan me bijna niet voorstellen dat een framework als Symfony niet flexibel genoeg is.
Ik stuur zelf met enkele controllers hele websites aan. De meeste routes maak ik gewoon aan in het CMS en in technische termen wordt er voor het gros van de pagina's gebruik gemaakt van één dynamische route en één controller.
De controllers die er bij komen zijn meestal van de geïnstalleerde extra bundles. Deze bundles bieden een fortuin aan functionaliteit en zijn in enkele minuten te installeren en te configureren, wanneer je er mee bekend bent natuurlijk.

Fouten die in de code voorkomen kunnen verholpen worden. Maar je gaat problemen krijgen als je voor tientallen klanten of websites telkens dezelfde fouten moet gaan oplossen, of oplossingen niet meer compatible blijken te zijn. Dan wordt het al gauw een rommeltje. Modulair werken en versiebeheer worden dan ook heel erg belangrijk. Vraag me inmiddels af hoever jullie daar mee zijn.
 
Rob D

Rob D

12/12/2016 12:01:27
Quote Anchor link
Frank, ik denk dat je laatste vraag niet rechtstreeks met mijn oorspronkelijke vraag te maken heeft en misschien meer iets voor een ander forum. Maar ik wil je toch graag antwoorden.
Waarom denk je dat, als je niet gebruik maakt van Symphony, Laravel of Yii, dat je dan niet modulair kan werken? Wat heeft een framework te maken met Contiunues Delivery met GIT als onderdeel?
Natuurlijk werken wij met modules, imports van bestaande packages en versie beheer. Maar het hoe en welke
bepalen we nu zelf. Wij werken op onze manier al jaren, met een kleine bezetting, tot tevredenheid van onze
klanten. Wij gebruiken 1 framework voor verschillende klanten, vanuit tientallen landen, van over de hele wereld, met elk hun eigen talen en locale.
Dit kunnen wij alleen doen door zeer efficient onze software in te zetten. Echter zo'n oud systeem ontkomt niet aan de beruchte 'software rot'.

Ik kijk dus dan ook met belangstelling naar vernieuwing, waar een framework als Symphony een mogelijk goede optie is. Echter ben ik bang dat het ons, met de bezetting die we hebben en de continue oplever druk van de klant, jaren zal duren om onze code om te zetten. Dit legt een veel te grote druk op onze capaciteit. Wel wil ik onze software proberen deel voor deel om te buigen naar mainstream methoden zodat een eventuele migratiestap naar een regulier framework realistischer wordt.

Dus in theorie heb je gelijk, maar ik heb te maken met de praktijk en moet dit dus pragmatisch oplossen.


Toevoeging op 12/12/2016 12:11:09:

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.
 
Ward van der Put
Moderator

Ward van der Put

12/12/2016 12:41:01
Quote Anchor link
Elke codebasis die 10 tot 15 jaar oud is, bevat onderdelen die (soms hopeloos) verouderd zijn. Dat geldt juist ook zeker voor PHP, want PHP 7 gebruik je anno bijna-2017 op veel onderdelen echt anders dan zo'n tien jaar geleden.

Als ik bijvoorbeeld dit zie, dan denk ik: service locator!
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
<?php
$controller
= new $class();
$controller->initLocale($country, $language);
?>

Elke controller moet apart geïnitialiseerd worden met land én taal? Zijn er dan geen controllers die prima werken zonder land en taal als twee God particles voor alles overheersende dependencies? En ook over het apart initialiseren van een controller en de rol van een constructor daarbij zijn in het laatste decennium boekwerken aan blogposts volgeschreven.

Als je dit wilt refactoren, dan zou ik waarschijnlijk niet met de routing beginnen. Begin met de fundamentelere bouwstenen, zoals gestructureerde namespaces voor core en apps en een fatsoenlijke autoloader die daarop aansluit.

Ik denk persoonlijk niet dat een PHP-framework bij zo'n grote live codebasis in combinatie met beperkte mensen en middelen (tijd!) de ideale oplossing is: dan moet je te veel ineens verbouwen.
 
Rob D

Rob D

12/12/2016 12:57:26
Quote Anchor link
Exact Ward, en dat ben ik nu aan het onderzoeken. Dat is wat ik bedoel met 'sofware rot'. Wij zijn de afgelopen jaren alleen maar bezig geweest met bouwen, bouwen en bouwen, zonder afstand te nemen van wat en waarmee we aan het bouwen zijn. We wisten dat het op een andere manier zou moeten, maar konden niet anders want we moesten overleven, dat is de praktijk.
We gaan dus nu onze software aanpakken, maar dat moet gefaseerd gaan en misschien eindigen we wel met Symphony, of eerder Laravel:)

Waar ik wel moeite mee heb is het idee, dat als je geen regulier framework gebruikt, dat je dan fout/dom bezig bent. Ik heb teveel methologien, dogma's, hypes zien komen en gaan, waaronder vele waarvan ik achteraf blij ben dat ik er in ben meegegaan. Er zijn ook genoeg grote(cms/social) producten op de markt die ook hun software baseren op eigen frameworks (en vaak niet al te mooi gebouwd).

Toch als, zoals in ieder bedrijf, standaardisatie belangrijk is het zinvol om altijd (af)kijken naar wat kant en klaar en beproeft beschikbaar is.
 
Ward van der Put
Moderator

Ward van der Put

12/12/2016 14:35:51
Quote Anchor link
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.
 
Frank Nietbelangrijk

Frank Nietbelangrijk

13/12/2016 13:05:07
Quote Anchor link
Beste Rob,

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.

Cheers
 
Thomas van den Heuvel

Thomas van den Heuvel

13/12/2016 14:31:35
Quote Anchor link
Waarom moet het altijd of vanille- of chocolade-vla zijn? :/

Maak/doe eens een uitstapje/onderzoek en/of draai een project met een ander framework. Wie weet steek je er iets van op.
Gewijzigd op 13/12/2016 14:32:57 door Thomas van den Heuvel
 
Mr Beronne

Mr Beronne

13/12/2016 20:51:11
Quote Anchor link
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.
 
Rob D

Rob D

13/12/2016 22:07:32
Quote Anchor link
Hi Frank en Mr. Beronne,

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.


Toevoeging op 13/12/2016 22:32:28:

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 ...

Toevoeging op 14/12/2016 09:53:40:

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.
 
Ward van der Put
Moderator

Ward van der Put

14/12/2016 11:29:51
Quote Anchor link
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:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
<?php
var_dump(  empty($nonexistent) );  // bool(true)
var_dump( !empty($nonexistent) );  // bool(false)
var_dump(  isset($nonexistent) );  // bool(false)
?>
Gewijzigd op 14/12/2016 11:32:45 door Ward van der Put
 
Rob D

Rob D

14/12/2016 12:53:13
Quote Anchor link
Ja, het kwartje is gevallen, ik snap het.

Dank julle beide.
 
Ozzie PHP

Ozzie PHP

14/12/2016 15:22:46
Quote Anchor link
Rob D op 13/12/2016 22:07:32:
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.
 
Rob D

Rob D

15/12/2016 09:04:58
Quote Anchor link
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.
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.