Ik zit er aan te denken om nog eens wat in PHP te gaan doen. Als basis wil ik eerst en vooral een degelijk 'usermangement system' opzetten. Dit in een object gericht concept.
Omdat hierbij zowel het databaseontwerp als het implementeren van de code zelf belangrijk zijn, zou ik deze graag beiden bespreken.
De database zou ik als volgt willen inrichten:
Misschien kort even het schema toelichten:
In de database wordt over elke gebruiker wat basisgegevens bijgehouden. Er kunnen eventueel een aantal opmerkingen gemaakt worden over een gebruiker. (bv. zijn specifieke functie op de website). Verder is er verplicht een koppeling met de permissies tabel. Uiteraard, behoord een 'permissie-entry' altijd aan 1 specifieke gebruiker. (kleine opmerking hieronder) Verder worden alle belangrijke zaken die een gebruiker uitvoert gelogd. Tot slot is er nog een tabel met sessies in (Ik ben van plan een eigen session handler te programmeren die via de database werkt.) Elke sessie verwijst naar 1 gebruiker.
[opmerking permissies]
Ik overweeg dit nog wat aan te passen, namelijk een toevoeging: groups. Elke gebruiker krijgt dan een group en een group krijgt op zijn beurt een aantal permissies.
In PHP zou ik dan volgende klassen bekomen:
Session, User, Log, Note. Wat deze doen, lijkt mij vanzelfsprekend. Indien dat niet het geval zou zijn, wil ik dit gerust even toelichten.
Ik loop nu bij nader inzien op deze manier toch nog tegen een probleem. Wanneer ik een User object wil maken, ben ik verplicht een Person object aan te maken (of de parameters in te vullen die dat mogelijk maken).
Dit is geen grote ramp, maar toch... Bij het inloggen bijvoorbeeld, heb ik totaal geen behoefte aan de gegevens van een persoon. Toch moet ik deze ophalen, wat dus onnodige queries kost. En nee, deze info wil ik niet gaan opslaan in de sessie, net omdat ik het zo weinig nodig heb.
Daarom overweeg ik het niet Person te extenden, maar User. Alleen weet ik niet of dit echt een goede oplossing is. Het klinkt in elk geval niet erg logisch. Graag jullie raad!
Ik zou Person er alleen bij betrekken als je daadwerkelijk die informatie nodig hebt.
En als User niet hetzelfde is als Person, waarom moeten ze dan 1 op 1 gelinkt worden?
Persoonlijk zou ik user_id en person_id gewoon als relatie beschouwen, maar dan alleen als je dat nodig hebt.
Person extend dus User.
User = id, loginnaam (kan ook email zijn), wachtwoord, sessie en rechten
Person = id, naam, email, leeftijd (en andere profiel-dingen)
Bedankt voor de reactie Eddy. Ik wacht nog even af op andere reacties. Maar het lijkt me inderdaad een goed plan. Al zijn er misschien nog wel betere oplossingen :-)
Verder heb je het denk ik wel meer over de database kan dan de PHP kant lijkt mij. Want ik zie bijvoorbeeld niet in waarom ik het wachtwoord in een User object zou opslaan.
Dit is geen grote ramp, maar toch... Bij het inloggen bijvoorbeeld, heb ik totaal geen behoefte aan de gegevens van een persoon. Toch moet ik deze ophalen, wat dus onnodige queries kost. En nee, deze info wil ik niet gaan opslaan in de sessie, net omdat ik het zo weinig nodig heb.
Moeten is een groot woord. Ik kan null etc invullen, maar goed. Dan zit ik alsnog met een ongewenst / onnodig object. Als ik het er volledig uit sloop, dan kan ik even goed niet langer extenden.
Want ik zie bijvoorbeeld niet in waarom ik het wachtwoord in een User object zou opslaan.
Omdat een user/gebruiker moet kunnen inloggen met een wachtwoord?
Die hoef/mag je uiteraard niet opslaan in een sessie, maar om te wijzigen etc wel.
Was ook maar een voorbeeld: wellicht logged_in BOOLEAN is beter ;).
Nu ik er wat beter naar kijk zit er uberhaupt iets heel geks in je opbouw:
<?php
class User extends Person implements Serializable {
public function __construct(Person $person...){
}
}
?>
De class User extends de class Person en je moet er nog een meegeven in de constructor. Dat is iets wat overbodig is en wat je nooit zou moeten doen. Alle data/methods die je nodig zou kunnen hebben in de class User heb je al, dus waarom nog eens meegeven?
Je zou je moeten afvragen of dat extenden uberhaupt nodig is.
[size=xsmall]Toevoeging op 07/09/2012 11:58:42:[/size]
En nog even terug naar een al wat oudere opmerking van je, maar mogelijk nu weer relevant.
Write Down op 04/09/2012 19:03:32
Ik dacht het net omgekeerd te doen. De bedoeling is namelijk dat ik het User object serialize en in de sessie ga stoppen. Dit wil ik dus liefst zo klein mogelijk houden.
Dat maakt niet uit. Bij het serializen bepaal je zelf welke gegevens je meeneemt. Zelfs al heb je 10MB aan data in het object zitten, als jij alleen het id van het object wil serialiseren dan kan dat natuurlijk.
Gezien je vragen is het misschien niet zo handig om het te extenden. En 'handig' is in elk geval geen juiste reden om het wel of niet te doen. Nodig wel.
Maar of het wel of niet moet is vanaf een afstand niet of nauwelijks te beantwoorden.
Stel jezelf eens de vragen:
- is Person dezelfde entiteit als User?
- is User dezelfde entiteit als Person?
- heb je de gegevens/methodes van User nodig in Person?
- heb je de gegevens/methodes van Person nodig in User?
- kan je gegevens/methodes die je in beide nodig hebt uitfilteren en wellicht in een gemeenschappelijke class onderbrengen?
Bedankt voor je reactie Erwin, uiteraard ook dank voor de andere reacties.
Ik zit nog steeds een beetje met een twijfel of ik ze nu al dan niet ga uit mekaar trekken. Ik wil nl. de mogelijkheid hebben om 'losse' personen aan te maken. Denk bijvoorbeeld aan het toevoegen van contactpersonen aan de applicatie. Ik zou bijvoorbeeld kunnen bijhouden wie mijn contactpersoon bij mijn hosting is. Die persoon is dus eigenlijk totaal geen gebruiker.
Anderzijds, is een gebruiker sowieso een persoon. Als ik iemand als gebruiker toevoeg, zou ik ook graag wat informatie over die persoon willen bijhouden. Vanuit dat punt, ben ik er vanuit gegaan dat er eigenlijk wel een relatie 'moet' zijn tussen beide klassen.
Verder ben ik vrij zeker dat de kans dat ik meer gebruikers (die dus ook 'persoon' zijn) heb dan enkel en alleen personen. Daarom dus toch nog enige twijfel.
