modules en mvc
Ik meen in bepaalde frameworks wel eens gezien te hebben dat men gebruikt maakt van modules. Nu vraag ik me af wat een module precies is, en of modules ook gebruikt (kunnen) worden in MVC opzet.
Ik stel me een module voor als een soort onderdeel (een blok) van een blokkendoos met een bepaalde functie. Dit blok kun je aan- en uit zetten. Bijv. een nieuwsbrief module. Standaard staat deze module bijvoorbeeld uit, maar als de klant dat wil dan kan de module worden ingeschakeld en dat kost de klant dan xxx euro.
Dat is een beetje hoe ik een module zie. Klopt dat?
Tegelijkertijd vraag ik me af of je in een MVC opzet ook met modules kunt werken. In het voorbeeld van een nieuwsbrief module zou ik me kunnen voorstellen dat je gewoon een nieuwsbrief controller, model en view maakt. Maar waar in dit verhaal hoort dan zo'n module thuis? Of werkt MVC niet met modules?
De MVC opzet zoals ik die ken ziet er op de server (globaal!!) zo uit:
De vraag is dus:
- Kun je in een MVC opzet met modules werken?
- Waar plaats je die op de server?
- Waaruit bestaat een module?
Ik ben erg benieuwd!
Gewijzigd op 08/01/2013 00:14:34 door Ozzie PHP
client->controller->module->view
is in mijn geval niet geheel mvc maar lijkt er wel sterk op. Ik plaats de modules in een map modules, alles is zo geregeld dat ik alleen de module hoef up te loaden als de klant een module wilt. In mijn geval is de module eigenlijk een mini-applicatie die bijvoorbeeld bij een nieuws module het nieuws kan ophalen etc. Maar dit is hoe ik het zie, ik weet niet of dit de standaard is.
Toevoeging op 08/01/2013 01:07:48:
Ik moet natuurlijk ook nog de news template uploaden bij activatie.
En wat voor bestanden zitten er dan in jouw module?
verder ik ik ook global instanties van klasse voor instanties die ik in elke module nodig heb maar deze instanties maak in dan aan in bijvoorbeeld de index.php. Ook heb ik een klasse globals om instanties op te halen uit de $GLOBALS.
ik doe dan bijvoorbeeld:
Code (php)
1
2
3
4
5
6
7
8
9
10
2
3
4
5
6
7
8
9
10
<?php
$smarty = globals::createSmartyFromGlobals();
$news = new news();
$news->doeIets();
$smarty->assign(doe iets);
smarty->fetch(news.tpl);
$smarty->display(index.tpl);
?>
$smarty = globals::createSmartyFromGlobals();
$news = new news();
$news->doeIets();
$smarty->assign(doe iets);
smarty->fetch(news.tpl);
$smarty->display(index.tpl);
?>
smarty regelt de rest en is dus eigenlijk een beetje de view.
Natuurlijk is dit een beperkt voorbeeld.
Dus eigenlijk heel simpel gezegd. In een normaal MVC zou er dit gebeuren:
www.mijnsite.nl/nieuwsbrief
Model <-> Nieuwsbriefcontroller (wordt aangeroepen door FrontendController) -> View
Jij hebt dan meer zoiets denk ik:
www.mijnsite.nl/nieuwsbrief
Module (wordt aangeroepen door FrontendController) <-> Smarty -> View
Jouw verhaal is duidelijk, thanks.
Ik ben benieuwd of er nog meer reacties komen en vooral of iemand een antwoord weet op de vragen in mijn openingspost.
Gewijzigd op 08/01/2013 01:41:52 door Ozzie PHP
de module is zoals ik al aangaf een soort mini-applicatie en heeft ook een soort van sub controller. Ik vond dit zelf de beste manier voor wat ik wou. MVC is natuurlijk een aparte structuur, zodra je hier iet aan aanpast het het geen MVC meer.
Nee, en juist daarom ben ik zo benieuwd of modules met MVC gecombineerd kunnen worden, of dat dat gewoon een dikke no-go is. Ben benieuwd naar de overige reacties...
Simpel gezegd
M V
\ /
C
Met andere woorden:
- Controller = plakmiddel
- Module = Logica
- View => uiterlijk
Ik denk dat een module is wat je een module wilt noemen...bijvoorbeeld je hebt core functionaliteit, en alles wat je er bij in wilt pluggen is een module. dit kunnen templates zijn, beheeronderdelen etc. Bij Joomla is een module een functionaliteit op de frontend (menu, poll, loginformulier)
ik heb momenteel een cmsje op basis van MVC. en dat werkt prima. of je het nog Model View Controller kunt noemen als je een module in een mapje Module plaatst:
Dit is zo ongeveer mijn structuur, in de Controller gebruik ik de Commandpattern.
Nu is bovenstaand structuur iets simpeler, maar een module zit in een mapje "admin" of "site" en View en Controller hebben ook die mapjes.
- Public
- Gallery
- CSS
- JS
- Application
- Controllers
- Library
- Models
- Views
Een bundle groepeert bepaalde functionaliteiten. Zo heb je een FOSUserBundle, voor het hele authenticatie en authorizatie gedoe, en een SonataAdminBundle, voor een admin panel en alles wat erbij hoort (hierbij hoort niet de functionaliteit van de USerbundle), en je hebt bijv. een WjBlogBundle die zorgt voor bepaalde functionaliteiten dat een blog werkt (het zorgt bijv. voor een blog widget in de admin interface en hij zorgt hoe de blog artikelen getoond worden op de site).
In de mappen structuur ziet het er dan zo uit:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
src/
Wj/
BlogBundle/
Controller/
PostController.php
PageController.php
Admin/
BlogAdmin.php (de klasse voor de widget in het admin panel)
Resources/
config/
... configuratie files voor deze bundle
public/
... css en js files voor deze bundle
views/
Post/
single.html.twig
...
WjBlogBundle.php
Sonata/
AdminBundle/
...
SonataAdminBundle.php
FOS/
UserBundle/
...
FOsUserBundle.php
Wj/
BlogBundle/
Controller/
PostController.php
PageController.php
Admin/
BlogAdmin.php (de klasse voor de widget in het admin panel)
Resources/
config/
... configuratie files voor deze bundle
public/
... css en js files voor deze bundle
views/
Post/
single.html.twig
...
WjBlogBundle.php
Sonata/
AdminBundle/
...
SonataAdminBundle.php
FOS/
UserBundle/
...
FOsUserBundle.php
Iedere website wil ik z'n eigen MVC en library geven en ik wil daarnaast een universeel beheergedeelte gaan maken (ook met MVC en library) waar iedere website gebruik van kan maken.
Stel we hebben een website, leukesite.nl, dan zou de directory structuur er ongeveer zo uit zien:
Code (php)
1
2
3
4
5
6
7
2
3
4
5
6
7
private/domains/leukesite.nl/controllers
/library
/models
/views
public_html/domains/leukesite.nl/css
/images
/enz.
/library
/models
/views
public_html/domains/leukesite.nl/css
/images
/enz.
De directory structuur van het beheergedeelte zou er ongeveer zo uitzien:
Stel nu, een simpel voorbeeldje, via het beheergedeelte moet het mogelijk zijn om nieuwsberichten aan te maken, te editen en te verwijderen.
Ik zou dan volgens MVC bijvoorbeeld in het beheergedeelte in de controllers een map "news" kunnen maken met daarin een "NewsController" class. En hetzelfde zou ik kunnen doen voor de model. En in de views zou ik dan ook een mapje "news" maken. De directorystructuur zou er dan zoiets uitzien:
Code (php)
1
2
3
4
2
3
4
private/control/controllers/news/newscontroller.php
/library
/models/news/newsmodel.php
/views/news/index.phtml
/library
/models/news/newsmodel.php
/views/news/index.phtml
Nu heb ik 2 vragen:
1) Klopt het bovenstaande? Is dit inderdaad zoals een MVC opzet eruit hoort te zien?
2) Is dit op de lange termijn de meest handige manier om alles te onderhouden.
Stel dat je met modules zou werken, dan zou ik me bijvoorbeeld ook zoiets kunnen voorstellen (maar wellicht slaat dit nergens op dus ik ben benieuwd naar jullie meningen):
Het voordeel hiervan lijkt mij dat controller, model en view bij elkaar staan. Dat heeft ook wel weer iets moois.
Waar het mij eigenlijk vooral om gaat is dat ik het makkelijk onderhoudbaar wil maken. Ik wil wel iets van een MVC opzet gebruiken, maar ik weet dus niet of ik het beste gewoon MVC (+library) kan aanhouden, of dat ik vanuit het oogpunt van onderhoudbaarheid wellicht met modules moet gaan werken.
Wat is jullie ervaring / visie hierop?
Gewijzigd op 08/01/2013 16:54:31 door Ozzie PHP
Die laatste optie
Oké, stel ik ga voor de laatste optie... dan stap ik toch in feite af van de "normale" mvc structuur? Klopt dat? En zitten daar nog nadelen aan?
En hoe zou jij de structuur exact inrichten? Heeft een module bijvoorbeeld ook een eigen library? En kan een module meerdere controllers / models hebben (ik denk het niet)?
Is dit een goede opzet:
of is dit beter:
Code (php)
1
2
3
4
2
3
4
private/control/library
/module/news/newcontroller.php
/newsmodel.php
/newsview.phtml
/module/news/newcontroller.php
/newsmodel.php
/newsview.phtml
of dit?
Code (php)
1
2
3
4
2
3
4
private/control/library
/module/news/controller/controller.php
/model/model.php
/view/index.phtml
/module/news/controller/controller.php
/model/model.php
/view/index.phtml
Het zal waarschijnlijk ook een kwestie van persoonlijke smaak zijn, maar alle tips zijn welkom!
Zie mijn reactie boven die van jou
En stel dat ik op deze manier ga werken, maak je dan nog wel steeds gebruik van een overkoepelende library? Ik neem aan dat die gewoon behouden blijft?
Oh ja, is het slim om je modules te organiseren, of zet je alle modules los onder elkaar? Stel we hebben bijvoorbeeld een nieuwsbriefmodule en een bannermodule. Beiden vallen onder de categorie "marketing".
Ga je dan dit doen:
Code (php)
1
2
3
4
5
6
7
2
3
4
5
6
7
private/control/library
/module/marketing/banners/controller.php
/model.php
/view.phtml
/news/controller.php
/model.php
/view.phtml
/module/marketing/banners/controller.php
/model.php
/view.phtml
/news/controller.php
/model.php
/view.phtml
Van de ene kant is dit miscchien overzichtelijker, maar het nadeel is dat je vantevoren niet altijd weet of een bepaalde module onder een bepaalde categorie thuishoort. En als je daar pas naderhand achterkomt, moet je alle code aanpassen. Lijkt me niet handig. Echter als je alle modules los onder elkaar zet, krijg je misschien wel weer heeel veel modules. Heb je hier nog advies in?
Gewijzigd op 08/01/2013 17:18:38 door Ozzie PHP
In de mappen structuur zie je dat ook terug (de vendor is de eerste map en daarna komen de mappen met de bundles).
private/domains/leukesite.nl/modules/
Wat ik me wel nog afvraag... je zou dan dus ook algemene modules krijgen die voor iedere website gelden. Dan denk ik bijvoorbeeld aan een router. Ieder request moet door de router worden gestuurd. Maar nu heb je in het geval van een router, bijvoorbeeld ook een "Route" class. Je moet immers routes kunnen aanmaken. Waar zou je zo'n Route class dan laten? Stop je die in de overkoepelende library? Of stop je die ook in de module? Het mooiste lijkt me dan om die ook in de module te stoppen... maar moet je er die dan gewoon los ingooien?
Dit ziet er een beetje raar uit denk ik...
Een router is onderdeel van het framework en komt dan toch niet in het module systeem?
Ik zou een router ook niet zien als module, wat ik wel doe is in elke module een plug-in loader gebruiken voor delen van de website die ik overal nodig heb. Ik denk hier aan een menu uit de database. Maar hier ga ik wel uit van mijn systeem.