[PHP] MVC Mappen structuur (modulair)

[xehbit]

Beste Tweakers,

Ik ben al enige dagen aan het uitzoeken wat nou een mooie manier is om een web applicatie te maken welke op modules werkt. Dit wil ik gaan schrijven in PHP en het MVC framework is erg simpel (geen bestaand framework).

Het MVC framework heeft de volgende bestanden Model, View en de Controller. In deze mappen zet je de bestanden neer, maar in mijn geval Bestaan die MVC bestanden uit losse modules. Zo heb je bijvoorbeeld een module voor systeems instellingen, gebruikers beheer, uren registratie etc...

Ik zie vaak dat de mappen structuur op de volgende manier wordt aangemaakt;
~/app/model/*.model.php
~/app/view/*.view.php
~/app/controller/*.controller.php

Omdat mijn systeem op modules gebaseert is lijkt mij het mij een betere manier om de volgende structuur aan te maken;
~/app/{modulename}/model/*.model.php
~/app/{modulename}/view/*.view.php
~/app/{modulename}/controller/*.controller.php
~/app/{modulename}/routes.php

Is dit een redelijk juiste manier om dit zo uit te voeren, of hebben jullie misschien betere ideeen ?

[johnkeates]

Ik zou modules niet in je app root zetten maar in een subdir zoals modules/ of library/ ofzo.

~/app/model/*.model.php
~/app/view/*.view.php
~/app/controller/*.controller.php
~/app/library/*

en dan dus:

~/app/library/{modulename}/model/*.model.php
~/app/library/{modulename}/view/*.view.php
~/app/library/{modulename}/controller/*.controller.php
~/app/library/{modulename}/routes.php

bijv.

Als je het een beetje leuk doet met juiste namespaces enzo kan je dat ook meteen prettig gebruiken.

[ Voor 73% gewijzigd door johnkeates op 01-09-2014 22:50 ]

[Styxxy]

Je kan eens kijken naar "areas" in ASP.NET MVC.

[PatrickH89]

Dragon707 schreef op maandag 01 september 2014 @ 22:46:
Beste Tweakers,

Ik ben al enige dagen aan het uitzoeken wat nou een mooie manier is om een web applicatie te maken welke op modules werkt. Dit wil ik gaan schrijven in PHP en het MVC framework is erg simpel (geen bestaand framework).

Het MVC framework heeft de volgende bestanden Model, View en de Controller. In deze mappen zet je de bestanden neer, maar in mijn geval Bestaan die MVC bestanden uit losse modules. Zo heb je bijvoorbeeld een module voor systeems instellingen, gebruikers beheer, uren registratie etc...

Ik zie vaak dat de mappen structuur op de volgende manier wordt aangemaakt;
~/app/model/*.model.php
~/app/view/*.view.php
~/app/controller/*.controller.php

Omdat mijn systeem op modules gebaseert is lijkt mij het mij een betere manier om de volgende structuur aan te maken;
~/app/{modulename}/model/*.model.php
~/app/{modulename}/view/*.view.php
~/app/{modulename}/controller/*.controller.php
~/app/{modulename}/routes.php

Is dit een redelijk juiste manier om dit zo uit te voeren, of hebben jullie misschien betere ideeen ?

Mag ik vragen waarom je niet een bestaand framework wilt gebruiken? In die structuur die je daar zet zie ik niet zoveel nieuws en het is zonde om het wiel opnieuw uit te vinden (tenzij je het als leerzame oefening wilt doen natuurlijk).

[xehbit]

johnkeates schreef op maandag 01 september 2014 @ 22:48:
Ik zou modules niet in je app root zetten maar in een subdir zoals modules/ of library/ ofzo.

~/app/model/*.model.php
~/app/view/*.view.php
~/app/controller/*.controller.php
~/app/library/*

en dan dus:

~/app/library/{modulename}/model/*.model.php
~/app/library/{modulename}/view/*.view.php
~/app/library/{modulename}/controller/*.controller.php
~/app/library/{modulename}/routes.php

bijv.

Als je het een beetje leuk doet met juiste namespaces enzo kan je dat ook meteen prettig gebruiken.

Dat zou dan betekenen dat er eigenlijk alleen de inlog pagina in die mappen komt te staan. Mijn idee was eigenlijk een login module welke je standaard bij elke installatie krijgt en vervolgens losse modules erbij kan 'prikken'.

PatrickH89 schreef op maandag 01 september 2014 @ 23:02:
[...]


Mag ik vragen waarom je niet een bestaand framework wilt gebruiken? In die structuur die je daar zet zie ik niet zoveel nieuws en het is zonde om het wiel opnieuw uit te vinden (tenzij je het als leerzame oefening wilt doen natuurlijk).

De reden dat ik zelf een framework wil maken is voornamelijk een oefening. Daarnaast, wanneer ik iets anders zou willen in een framework ben ik vrij om het zo aan te passen. Het nadeel van een bestaand framework is dat het ook wel mogelijk is maar je gelijk niet meer kunt updaten etc.. en je eigenlijk vast zit daaraan.

[ Voor 8% gewijzigd door xehbit op 01-09-2014 23:11 ]

[PatrickH89]

Dragon707 schreef op maandag 01 september 2014 @ 23:09:

[...]

De reden dat ik zelf een framework wil maken is voornamelijk een oefening. Daarnaast, wanneer ik iets anders zou willen in een framework ben ik vrij om het zo aan te passen. Het nadeel van een bestaand framework is dat het ook wel mogelijk is maar je gelijk niet meer kunt updaten etc.. en je eigenlijk vast zit daaraan.

Een goed framework kenmerkt zich oa door goede uitbreidingsmogelijkheden zonder de 'core te moeten hacken'. Als oefening is het altijd handig, maar kijk dan vooral goed naar hoe frameworks dingen doen en waarom ze dat zo doen.

[Verwijderd]

Dragon707 schreef op maandag 01 september 2014 @ 23:09:
De reden dat ik zelf een framework wil maken is voornamelijk een oefening. Daarnaast, wanneer ik iets anders zou willen in een framework ben ik vrij om het zo aan te passen. Het nadeel van een bestaand framework is dat het ook wel mogelijk is maar je gelijk niet meer kunt updaten etc.. en je eigenlijk vast zit daaraan.

Dit argument hoor ik vaker. Maar snap deze niet. Het bestaand framework is altijd beter dan hetgeen wat jij nu gaat neerzetten. Sorry maar zo is het. Daar zit al aanzienlijk meer tijd in en security fixes dan jij momenteel in jouw framework hebt zitten.Daarnaast, kun je natuurlijk aanpassingen doen in het framework, dat je niet kan updaten? So what? Jouw eigen framework update je toch ook niet via externe factoren? Als jij ervoor kiest een framework in eigen beheer te trekken, dan houd niemand je tegen om een bestaand framework te hacken naar eigen wensen.

[xehbit]

Verwijderd schreef op dinsdag 02 september 2014 @ 10:54:
[...]


Dit argument hoor ik vaker. Maar snap deze niet. Het bestaand framework is altijd beter dan hetgeen wat jij nu gaat neerzetten. Sorry maar zo is het. Daar zit al aanzienlijk meer tijd in en security fixes dan jij momenteel in jouw framework hebt zitten.Daarnaast, kun je natuurlijk aanpassingen doen in het framework, dat je niet kan updaten? So what? Jouw eigen framework update je toch ook niet via externe factoren? Als jij ervoor kiest een framework in eigen beheer te trekken, dan houd niemand je tegen om een bestaand framework te hacken naar eigen wensen.

Je hebt daar inderdaad gelijk in, maar ik wil een simpel framework hebben wat niets anders doet dan alleen het routen/parsen van de request en het inladen van de MVC bestanden. Zonder toeters en bellen er omheen.

[_Moe_]

Dragon707 schreef op dinsdag 02 september 2014 @ 11:01:
[...]


Je hebt daar inderdaad gelijk in, maar ik wil een simpel framework hebben wat niets anders doet dan alleen het routen/parsen van de request en het inladen van de MVC bestanden. Zonder toeters en bellen er omheen.

Mm, wat is een framework volgens jou?
Die toeters en bellen kan je bij de meeste frameworks gewoon laten vallen als je ze niet nodig hebt.

[BeRtjh]

Dragon707 schreef op dinsdag 02 september 2014 @ 11:01:
[...]


Je hebt daar inderdaad gelijk in, maar ik wil een simpel framework hebben wat niets anders doet dan alleen het routen/parsen van de request en het inladen van de MVC bestanden. Zonder toeters en bellen er omheen.

Kijk bijvoorbeeld eens naar Symfony en hoe zij gebruik maken van Composer om dit probleem op te lossen.

[ Voor 6% gewijzigd door BeRtjh op 02-09-2014 11:16 ]

[Donderpoes]

Pak een router package: https://packagist.org/search/?q=router en maak gebruik van composer. Dan voldoet het aan jouw omschrijving, uitgezonderd het punt framework. Maar dit lijk je ook niet te willen.

ik wil een simpel framework hebben wat niets anders doet dan alleen het routen/parsen van de request en het inladen van de MVC bestanden

[Barryvdh]

Of Silex dus.

[xehbit]

Maargoed dat over Framework, wat is een beetje juiste manier van de folders aanmaken. Wat ik eerst aan zat te denken was om het volgende te doen:

~/model/{module}/*.model.php
~/view/{module}/*.view.php
~/controller/{module}/*.controller.php

Maar het nadeel hiervan is weer dat je niet 'even makkelijk' een module kan toevoegen door een folder er in te slepen (dit zou je dan in het geval hierboven 3x moeten doen).

[_Moe_]

Ik zou dit als volgt doen
~/modules/module/models/*.model.php
~/modules/module/views/*.view.php
~/modules/module/controllers/*.controller.php

~/app/models/*.model.php
~/app/views/*.view.php
~/app/controllers/*.controller.php

Vervolgens kan je met behulp van namespaces in de route file of app files de nodige info retourneren.

[kwaakvaak_v2]

Donderpoes schreef op dinsdag 02 september 2014 @ 11:35:
Pak een router package: https://packagist.org/search/?q=router en maak gebruik van composer. Dan voldoet het aan jouw omschrijving, uitgezonderd het punt framework. Maar dit lijk je ook niet te willen.


[...]

Het grappige is, dat de makers van die router componenten waarschijnlijk ook te horen hebben gekregen van andere 'stuurlui aan de wal' dat ze beter bestaande componenten kunnen gebruiken omdat het zonde van de tijd is. En toch hebben ze hun router gemaakt en zijn er blijkbaar meer mensen die zich kunnen vinden in hun specifieke visie op hoe een router zou moeten werken.

Dus als iemand nu perse zijn eigen router of wat dan ook wil schrijven, laat ze vooral doen. Kunnen ze daarna helemaal zelf tot de conclusie komen dat hun idee geniaal of crap was..

[Gomez12]

Dragon707 schreef op dinsdag 02 september 2014 @ 13:06:
Maargoed dat over Framework, wat is een beetje juiste manier van de folders aanmaken. Wat ik eerst aan zat te denken was om het volgende te doen:

~/model/{module}/*.model.php
~/view/{module}/*.view.php
~/controller/{module}/*.controller.php

Maar het nadeel hiervan is weer dat je niet 'even makkelijk' een module kan toevoegen door een folder er in te slepen (dit zou je dan in het geval hierboven 3x moeten doen).

Ik zou hiervoor kiezen, dan heb je alle gelijke soorten logica binnen dezelfde mappen zitten (model-logica / view-logica en controleer-logica).

En je "nadeel" zou ik simpelweg oplossen door als 1e module een install-module te introduceren.

Want als je het groter wilt maken / meer modules wilt maken dan ga je op een gegeven moment vanzelf tegen het feit aanlopen dat er modules zijn die bepaalde mappen delen logica niet gaan hebben (bijv een exotische database module die zal op zich geen view-logica hebben)
en dan krijg je met je 1e opzet dus modules map met daarin 100 submappen en dan moet je daarin gaan filteren terwijl ik het altijd veel plezieriger vind om 50 view-modules te hebben zodat als ik iets view-logica wil veranderen dat ik enkel die 50 submappen zie die ook echt viewlogica bevatten ipv dat ik 100 modules voor mijn kiezen krijg waarvan er 50 geen views bevatten

[Barryvdh]

Het ligt er ook aan wat het doel is van je modules. Als je ze wil gaan hergebruiken door ze te kopïeren (of een composer package van maken) zou het makkelijker om ze wel per module op te splitsen. Dat een van die modules dan geen views heeft maakt natuurlijk niet uit.

In Laravel gebruiken ze daar bijvoorbeeld ServiceProviders voor, dat is een soort configuratie bestand dat je views op een bepaalde manier laadt, evt controllers/routes toevoegt etc.

Als het gewoon voor 1 applicatie is, zet ik het meestal gewoon alle views in de map views, alle controllers bij elkaar etc. Dat is inderdaad wat makkelijker.

Ik zou er overigens wel voor kiezen om alles via PSR-4 te ordenen. Ik weet niet waarom je .model.php of .view.php in je naam zou zetten, maar geef je classes gewoon fatsoenlijk namen en gebruik namespaces.

Dus

MyApp\Controllers\ProductController -> app/Controllers/ProductController.php
MyApp\Models\Product - >app/Models/Product.php

Je views zijn niet echt classes toch? Ik weet niet wat je precies gebruikt om je views te renderen, maar als dat gewoon php bestanden zijn, zou ik ze op een bepaalde manier structureren, bijvoorbeeld app/views/products.php door '$template->render('products')'. En eventueel bij losse modules dus namespacen: app/modules/products/views/index.php -> $template->render('products::index')

Als je PSR-4 gebruikt kan je gewoon Composer gebruiken om alles te auto-loaden en komen je namespaces overeen met je mappen, dus dat is makkelijk te vinden.

[Verwijderd]

kwaakvaak_v2 schreef op dinsdag 02 september 2014 @ 16:11:
[...]
Het grappige is, dat de makers van die router componenten waarschijnlijk ook te horen hebben gekregen van andere 'stuurlui aan de wal' dat ze beter bestaande componenten kunnen gebruiken omdat het zonde van de tijd is. En toch hebben ze hun router gemaakt en zijn er blijkbaar meer mensen die zich kunnen vinden in hun specifieke visie op hoe een router zou moeten werken.

Dus als iemand nu perse zijn eigen router of wat dan ook wil schrijven, laat ze vooral doen. Kunnen ze daarna helemaal zelf tot de conclusie komen dat hun idee geniaal of crap was..

Die mensen begonnen niet met de vraag waarmee topic starter is begonnen. Wanneer je die vraag al stelt is het een vraagteken of je een eigen routing component moet willen opzetten.

Uiteraard, dit allemaal los van het feit als het puur ter educatie is.

[ Voor 4% gewijzigd door Verwijderd op 03-09-2014 09:54 ]

[xehbit]

Verwijderd schreef op woensdag 03 september 2014 @ 09:48:
[...]


Die mensen begonnen niet met de vraag waarmee topic starter is begonnen. Wanneer je die vraag al stelt is het een vraagteken of je een eigen routing component moet willen opzetten.

Uiteraard, dit allemaal los van het feit als het puur ter educatie is.

Mijn vraag ging eigenlijk niet eens over het framework of een router :-)

Maargoed, ik kan natuurlijk een router rule maken die er zo uitziet:

PHP:

Router::addRoute('GET', '/invoice/view/{:invoiceid}', 'app/finance/controller/invoice.controller.php');

Of iets in die richting wanner ik het volgende pad gebruik:
~/app/{module}/{model,view,controller}/*.php

[johnkeates]

Doe het op de bewezen manier van o.a. Yii, Symfony, ZF1/2, Cake enz. Gewoon een mapje dat modules of iets dergelijks heet (extensions, library, plugins enz) en daar per module een map met de module naam en daarin de standaard mappen. Je moet een module als een zelfstandig iets zien.

Daarnaast kan je ook prima je eigen core modules op die manier modulariseren, het is niet alsof het niet net zo goed modules zijn. Login kan je bijvoorbeeld standaard hebben, maar dat maak je dan gewoon de Login module. That said, Login is helemaal geen module maar eerder een user story. Ik zou dus een ding als een membership module of AAA module maken. En dan heb je ook een ACL module nodig.