[PHP] CI: Het gebruik van (H)MVC , modules, libraries etc.*

[Douweegbertje]

Beste Tweakers,

Even een intro:
Ik ben zelf vaak bezig geweest met kant en klare "frameworks" van mijn werkgever of standaard frameworks zoals CodeIgniter en bijvoorbeeld Zend.

Het grootste gedeelte is door mij zelf aangeleerd echter probeer ik toch vaak me zelf te verdiepen in fatsoenlijke codes en het gebruik van een bepaalde backend wat gewoon fatsoenlijk is opgebouwd.
Ik zie me zelf dan ook niet helemaal als een volwaardig coder, echter heb ik er toch heel veel plezier van om wat moeilijkere dingen uit te proberen dan een standaard PHP scriptje.

CodeIgniter

Mijn topic titel werd aardig groot, maar CI staat dus voor CodeIgniter. Ik heb voor dit Framework gekozen vanwege de documentatie en alle mogelijkheden die bestaan op basis van CI.
Nu heb ik al een paar simpele dingen gemaakt op basis van natuurlijk MVC.
Recentelijk kwam ik dus HMVC tegen: https://bitbucket.org/wir...extensions-hmvc/wiki/Home
waar ik ook nog wat vraagjes over heb.

Mijn vragen:

Ik ben dus steeds opzoek naar een juiste programmeer "manier", echter zijn een aantal dingen voor mij toch erg onduidelijk.
Mijn zoektochten op Google en gerelateerde forums van bijvoorbeeld CI hebben weinig tot niets opgeleverd.
Het grootste gedeelte van topics die je tegen komt zijn gebaseerd op specifieke programmeer voorbeelden.
Echter een leuke handleiding over HOE je nou een applicatie fatsoenlijk opbouwt kan ik gewoon niet vinden.

In feite, en dan wat grof neergezet zou ik graag wat hulp / informatie / links verkrijgen over:

- MVC / HMVC
Hoe breng je dit nou in de praktijk tot een goede applicatie. Hoe bouw je iets op, op een fatsoenlijke manier?
Mijn punt is dat ik heus wel een website / applicatie kan maken, maar wie zegt dat mijn opbouw nou fatsoenlijk is? Ok het werkt, maar dat zegt naar mijn mening niets.

- Librarys en Modules
Ik snap de basis van Libs en Modules, alleen wanneer gebruik je nou wat, en HOE maak je hier gebruik van? Even een verkapt voorbeeld:
Je zou een Lib. kunnen hebben voor nieuws items, wat dus je systeem ondersteunt. Maar in feite zou je ook gewoon een Module "nieuws" kunnen hebben, of zelfs een Module nieuws die je Lib. nieuws gebruikt.

- Opbouw van je applicatie
Hoe bouw je nou fatsoenlijk je applicatie op, en hoe gebruik je nou wat?

Wellicht kan ik een voorbeeld geven, dat hier antwoorden op worden gegeven over wat je nou gebruikt voor wat:

Voorbeeld:

Een CMS waarbij de volgende functies aanwezig zijn;

- Login -> Admin gedeelte
- Pagina's
- Modules op een pagina, denk aan: nieuws of een twitter box etc.


Dan had ik zelf bijvoorbeeld dit idee voor ogen:

Een bootstrap controller:

- Alle pagina request komen naar deze controller.
- De controller bekijkt of er een specifieke controller voor deze pagina is (denk dus aan het Admin gedeelte)
- Als het geen admin pagina is, dan zoekt hij in de database voor de specifieke pagina.

Dan heb ik "iets" nodig (mits het een pagina uit de database is) die vervolgens de data verwerkt die aan de pagina hangt.
Ik denk dan aan een "Page Module" die dus dingen ophaalt:
- Content
- Mogelijke Modules (bijv nieuws)
- Etc.

Vervolgens wordt alles weer terug gegeven en wordt de pagina weer gegeven.

Is dit nu een fatsoenlijke manier van "denken"?

Graag wat advies, en / of leeswerk van dingen die ik dus niet via google kon vinden.

Alvast bedankt

[Avalaxy]

Tja, hoe zet je een goede architectuur op... Op tig manieren, hangt heel erg af van wat je bouwt.

Ik heb zelf het idee dat jij het meest gebaat bent bij het lezen van wat goede boeken over design patterns. Zowel die van Gang of Four als de enterprise design patterns van Fowler.

Als je echt de concepten van loosly coupled applicaties begint te snappen en dergelijken is het al snel heel simpel allemaal en begin je zelfs tussen verschillende design patterns weer patterns te herkennen.

Design patterns zijn overigens niet je doel op zich, maar ze geven je een hoop inzicht in nette manieren om bepaalde zaken op te lossen. Vaak ben je al bezig met design patterns nog voor je het door hebt.

[ Voor 17% gewijzigd door Avalaxy op 17-03-2012 16:49 ]

[Douweegbertje]

Ok bedankt, zal eens wat boeken in die richting opzoeken.

[Verwijderd]

Dit kan je op ontzettend veel manieren uitvoeren. Wat je eerst duidelijk moet hebben: de functionaliteit. En hoe wil je het opzetten? Moet het kunnen groeien? Een boek over design patterns is sowieso een goede tip, alleen zorg dat je je functionaliteit uitwerkt en vandaar je architectuur opbouwd. Dus niet in de wilde weg wat patterns toevoegen

[Avalaxy]

Verwijderd schreef op zaterdag 17 maart 2012 @ 23:52:
alleen zorg dat je je functionaliteit uitwerkt en vandaar je architectuur opbouwdt. Dus niet in de wilde weg wat patterns toevoegen

Aan de ene kant mee eens, je focus blijft natuurlijk op het domein zelf liggen en niet op de techniek, echter kan het juist nuttig zijn om je eerst te focussen op een aantal patterns (generieke dingen, denk aan het opzetten van een service layer, repositories, unit of work, etc.) waarna je met deze flexibele/generieke basis juist weer makkelijk je domein-specifieke logica kunt gaan implementeren.

[HMS]

Avalaxy schreef op zondag 18 maart 2012 @ 01:18:
[...]


Aan de ene kant mee eens, je focus blijft natuurlijk op het domein zelf liggen en niet op de techniek, echter kan het juist nuttig zijn om je eerst te focussen op een aantal patterns (generieke dingen, denk aan het opzetten van een service layer, repositories, unit of work, etc.) waarna je met deze flexibele/generieke basis juist weer makkelijk je domein-specifieke logica kunt gaan implementeren.

Tenzij je een simpele CRUD applicatie gaat maken, die zaken die jij noemt ervaar ik dan als onnodige balast.

Domain Driven Design is iets wat je pas moet toepassen als je het ook daadwerkelijk nodig hebt.

Schijnbaar zegt de auteur van het DDD boek ook dat 99% van de applicaties DDD niet nodig heeft. Heb dit niet kunnen verifiëren helaas.

[kwaakvaak_v2]

Als je op het boek van Evans doelt, ik kan die passage niet vinden waarin staat dat applicaties het niet nodig hebben. Sterker nog hij schrijft zelfs dat de meeste projecten er wel baat bij hebben omdat het je vooraf dwingt na te denken over hoe je, je applicatie opzet.

[Douweegbertje]

Ik snap natuurlijk wel dat de juiste basis begint met het "papierwerk" vooraf, logisch gezien maak je natuurlijk eerst je planning over "hoe" en "wat" met de juiste workflows en diagramen etc. etc.
Verder denk ik dat jullie misschien net een stap te ver gaan in het proces dat ik zoek.
Tenminste het lijkt mij dat er op zich een logische opbouw voor een applicatie kan zijn, zonder dat je ver in de details treed, en / of details van je applicatie weet.

Even een voorbeeld van een naar mijn idee logische applicatie:

User:

user Controller -> vangt eigenlijk alle request op, en verwerkt deze richting de Model en / of naar de view.
user Model -> wordt aangeroepen via de controller om gegevens te verwerken
user View -> wordt aangeroepen via de controller om bijv. content te laten zien.

Stel dat je dan werkt met HMVC, in hoeverre laat je dan Modules (die dus ook hun eigen "MVC" patroon hebben) communiceren met de rest van je applicatie?

Wellicht leg ik het een beetje vaag uit, maar ik hoop dat het ongeveer duidelijk is.

In elk geval nog bedankt voor de reacties, heb ik weer even wat lees materiaal

[TheNephilim]

Kohana 3 is een echt HMVC framework, heb er een tijdje terug eens naar gekeken. Dit was me echter te onduidelijk en de documentatie hielp me ook niet verder.

Nu heb ik eens verder gekeken en toen kwam ik uit bij Symfony2. Dit is een relatief nieuw framework en hiervan is hele duidelijke documentatie aanwezig. Op de site zelf staat al zo vreselijk veel, dat je daar al heel ver mee komt. http://symfony.com/

Heb al wat dingen gelezen, maar ben nog nergens aan begonnen. Ikzelf heb ook vreselijke moeite met het opzetten van een basis. Nou moet ik nog zeker eens lezen hoor, maar nergens gewoon een simpel antwoord op hoe je nou werkelijk je onderdelen koppelt in MVC.

Even een simpele case:

Entiteiten
- Users
- Messages
- Friends

Je hebt een home pagina, ingelogde gebruikers kunnen berichten lezen en versturen. Dus met een controller voor User en Messages ben je dan een heel eind. Handelingen als CreateUser/SendMessage/AddToFriends (etc.) komen voorbij. Maar stel je hebt een pagina met een link naar een gebruiker, als de gebruiker een vriend is, is de kleur van de link blauw.

In welke controller stop je de functie om de link te maken, waarin dus word gechecked of degene die de pagina opvraagt een vriend is van gebruiker waarvan er een link is gemaakt moet worden?

Dergelijke vragen vind ik nergens in voorbeelden terug, het maken van controllers, routes etc is me bekend, maar juist de opzet voor grote websites ontbreekt hier nog. Uiteraard heb ik nog lang niet alles gelezen, maar ik dacht 'why not pop the question'?

[Verwijderd]

[b][message=37875571,noline]
Even een voorbeeld van een naar mijn idee logische applicatie:

Stel dat je dan werkt met HMVC, in hoeverre laat je dan Modules (die dus ook hun eigen "MVC" patroon hebben) communiceren met de rest van je applicatie?

Wat zou je willen laten communiceren dan? Ik heb een beetje het idee dat je je architectuur nu niet goed voor ogen hebt(no offense )
Je moet scheiding houden in je applicatie. Lees bijvoorbeeld ook: Wikipedia: Dependency inversion principle

@Avalaxy: Klopt, de scheiding is ook vaak moeilijk aan te wijzen. Wat betreft bepaalde patterns ben ik met je eens. Vaak is MVC of MC een goed pattern om toe te passen. Maar wat ik uit eigen ervaring merkte was dat ik patterns ging toepassen om maar patterns toe te passen (en ik heb een pattern uit je boek gelinkt )

[T i M]

douweegbertje schreef op zondag 18 maart 2012 @ 13:54:
Ik snap natuurlijk wel dat de juiste basis begint met het "papierwerk" vooraf, logisch gezien maak je natuurlijk eerst je planning over "hoe" en "wat" met de juiste workflows en diagramen etc. etc.
Verder denk ik dat jullie misschien net een stap te ver gaan in het proces dat ik zoek.
Tenminste het lijkt mij dat er op zich een logische opbouw voor een applicatie kan zijn, zonder dat je ver in de details treed, en / of details van je applicatie weet.

Even een voorbeeld van een naar mijn idee logische applicatie:

User:

user Controller -> vangt eigenlijk alle request op, en verwerkt deze richting de Model en / of naar de view.
user Model -> wordt aangeroepen via de controller om gegevens te verwerken
user View -> wordt aangeroepen via de controller om bijv. content te laten zien.

Stel dat je dan werkt met HMVC, in hoeverre laat je dan Modules (die dus ook hun eigen "MVC" patroon hebben) communiceren met de rest van je applicatie?

Wellicht leg ik het een beetje vaag uit, maar ik hoop dat het ongeveer duidelijk is.

In elk geval nog bedankt voor de reacties, heb ik weer even wat lees materiaal

Iedere module heeft zijn eigen controllers en views, maar niet hun eigen modellen.

- Models
- Modules
-- Admin
---Controllers
---Views
-- Default
---Controllers
---Views

Stel je hebt een model User, dan kan je die in beide modules gebruiken.

Daarnaast heb je nog ergens een mapje Lib waar je je eigen library kunt opbouwen, die je weer kunt aanspreken in beide modules.

[ Voor 4% gewijzigd door T i M op 19-03-2012 16:02 ]

[Verwijderd]

T i M schreef op maandag 19 maart 2012 @ 16:01:
[...]


Iedere module heeft zijn eigen controllers en views, maar niet hun eigen modellen.

- Models
- Modules
-- Admin
---Controllers
---Views
-- Default
---Controllers
---Views

Stel je hebt een model User, dan kan je die in beide modules gebruiken.

Daarnaast heb je nog ergens een mapje Lib waar je je eigen library kunt opbouwen, die je weer kunt aanspreken in beide modules.

Waarom zou een module niet zijn eigen model kunnen hebben. Een module kan toch iets toevoegen aan de applicatie? Dus naast logica ook nog een eigen stuk model.

[T i M]

Verwijderd schreef op maandag 19 maart 2012 @ 16:06:
[...]


Waarom zou een module niet zijn eigen model kunnen hebben. Een module kan toch iets toevoegen aan de applicatie? Dus naast logica ook nog een eigen stuk model.

Het kan natuurlijk wel, maar modellen staan centraal in je applicatie. Je hebt ook niet per module een aparte database instance.

[Verwijderd]

T i M schreef op maandag 19 maart 2012 @ 16:11:
[...]


Het kan natuurlijk wel, maar modellen staan centraal in je applicatie. Je hebt ook niet per module een aparte database instance.

Ja, maar ik kan bedenken dat je niet alle modellen van je modules in je models dir van je applicatie wilt hebben. Het idee van een module is in mijn ogen juist het plug&play gehalte. En wat betreft de database instance, dat hangt natuurlijk af van je design. Als je met modellen werkt, verwacht ik hopen dat je ook via een goede manier de database instantieert En daarbovenop is een model natuurlijk niet altijd gekoppeld aan een RDBMS. Ik zie bijvoorbeeld een twitter module wel een eigen model hebben. Die door middel van webservice calls de tweets ophaalt.

[ReenL]

Wow, hoop vragen, zoveel te vertellen. In deze reactie alleen mijn ervaring, geen feiten dus.

MVC / HMVC
Bij HMVC deel je, je applicatie op in kleine onderdeeltjes, elk onderdeel zijn eigen MVC. Wanneer je dit goed implementeert kun je dus elk onderdeel compleet los aanspreken. Denk aan nieuwsberichten, login, twitter. Ze staan normaal allemaal bij elkaar op 1 pagina. Bij HMVC kun je ze zonder moeite lostrekken.

Het nadeel van deze architectuur is dat je framework erop gemaakt moet zijn, anders is het praktisch niet bruikbaar. Een ander probleem is dat een "view" vaak compleet anders is in minimale vorm. Zie bijvoorbeeld hier op tweakers "nieuws" in de sidebar, op de frontpage, maar ook in de archieven. In theorie allemaal dezelfde code, maar in de praktijk zullen ze elk hun eigen views hebben.

Met MVC kun je hetzelfde bereiken door herbruikbare modules te schrijven en je templates netjes op te delen. Als je module bijvoorbeeld een functie getNews($amount, $offset) heeft, kun je die functie simpelweg vanuit een helper of plugin aanroepen en naar je template sturen.

Libraries en modules
In mijn projecten is een library iets wat je altijd kan gebruiken en niet afhankelijk is van de applicatie. De library mag zich dus nooit bewust zijn van de context van de applicatie. Een library weet bijvoorbeeld hoe een e-mail verstuurd moet worden, maar een library weet niet welke tekst hij erin moet stoppen of naar wie het verstuurd moet worden.

Opbouw van je applicatie
Het lijkt erop dat je op zoek ben naar het keyword router. Geef in je config aan naar welke controllers je bepaalde url's wilt routeren. De overige url's stuur je naar een "Page" routercontroller die vervolgens content laat zien of een 404 genereert.