[Alg] 3-lagenmodel

[AtlonXP1800]

Ik loop momenteel stage bij een klein bedrijfje dat websites ontwikkeld in PHP. Nu heb ik als opdracht om er voor te zorgen dat hun projecten beter worden opgezet, een deel daarvan is ook het verbeteren van de code.

Ik heb tijdens mijn opleiding geleerd om te werken met een 3 lagen model (gui, applicatie logica en db logica) en het lijkt mij dat dit binnen php ook nuttig is om nette systemen te maken.

Op dit moment wordt er al gebruik gemaakt van smarty, wat al een opslitsing tussen de php code, en de display logica geeft. Er wordt ook gebruikt van pear db_dataobject, wat de database operaties mooi appart zet (zelf schrijven van sql binnen je php code vrijwel niet nodig)

nu zit ik alleen met die middelste laag, de bussiness logica, wat kan je daar onder verstaan binnen php? De mensen bij het bedrijf zeggen dat dat index.php is, maar dat lijkt mij niet juist (als je netjes binnen 3 lagen wil werken, moet er vrijwel niets in index.php staan volgens mij, net als in je main bij een java programma)

Als je het wel objectgeorienteerd doet, is de kans groot dat de applicatie logica laag een doorgeef luik wordt, die eigenlijk niets doet (en alleen maar meer werk op levert)
Hoe moet het dan wel, vraag ik mij af?

Wie wil hier eens zijn visie over laten schijnen?

[Michali]

Hoezo een doorgeefluik? Je werkt dan toch gewoon met een set domein objecten, welke de benodigde gegevens bevatten en alle operaties daarop. Je gui maakt daar dan direct of via een service laag gebruik van. Overigens heeft een template systeem weinig met de scheiding van presentatie en business logica te maken. Als je je business logica tussen de code die je template vult zet, dan ben je net zo goed fout bezig als het mixen met pure HTML.

[rapture]

Dit is het model dat je bedoelt, bij ons op de hoge school wordt er aan 3-tier een andere interpretatie gegeven.

Presentatielaag (zoals presentation tier) met PHP code.

Data-accessor laag (zoals logic tier) met data-accessors om de database aan te spreken.

Data laag (dit is iets anders, database zien we als iets apart waar we geen code voor moeten proggen) met data-klassen, objecten moeten van bepaalde klassen afgeleid worden.

[ Voor 15% gewijzigd door rapture op 25-03-2006 12:50 ]

[whoami]

Je business logica is de 'core' van je applicatie.
Zoals Michali al zegt, bevat je business logica eigenlijk de 'domein classes' of, de classes die het probleem domein voorstellen. De business layer is de laag waar de 'beslissingen' genomen worden, zeg maar.

Je presentatie laag is verantwoordelijk voor het tonen van je gegevens, en zorgt ervoor dat de gebruiker je gegevens kan manipuleren. In die laag kan je een referentie hebben naar je business layer. Je presentatie laag gebruikt dan dus eigenlijk je business objecten (die in de business layer zitten), en het zijn die business objecten die bv. weten of een klant een slechte betaler is.
De logica die dat bepaalt, zit niet in je presentatie-laag, maar in je business-laag. Je presentatie - laag kan wel aan je business-laag vragen of een klant een slechte betaler is, en indien dit het geval is, een bepaalde waarschuwing tonen.

[whoami]

p&w->sea

[Verwijderd]

Ik zou persoonlijk bij webapplicaties eerst aan MVC denken waarbij je feitelijk al de view van het model scheidt. je model maakt verbinding met je DB en tada daar is je drie lagen structuur.

[Verwijderd]

Ik weet niet precies wat officieel als 'laag' gezien wordt, maar ik denk dat er wel meer lagen gebruikt kunnen worden. In het MVC Framework dat ik zelf gebruik is er een FilterChain met respectivelijk, SessionFilter (sessie storage regelen, DatabaseFilter (database verbinding regelen), InputFilter (input filteren) en als laatste de ExecutionFilter (voert de juiste actie in de juiste module uit, Action en Controller objecten zijn daar van belang).

Een eenvoudige Filter voor bijvoorbeeld security zou kunnen zijn:

PHP:

<?php 

class SecurityFilter extends Filter {
    
    function execute (&$filterChain)
    {
        $context    = &$this->getContext ();
        $controller = &$context->getController();
        $user       = &$context->getUser ();
        
        $action     = &$controller->getAction($controller->getModuleName(), $controller->getActionName());
        
        if ($action->isSecure () && !$user->isAuthenticated () && WEBAPP_AUTHENTICATION_USE == true) {
            $controller->forward (WEBAPP_AUTHENTICATION_MODULE, WEBAPP_AUTHENTICATION_ACTION);  
        }       

// pre action
        $filterChain->execute();    
// post action
    }
    
}

?>

Doordat de $filterChain->execute() wordt aangeroepen, en ExecutionFilter de laatste is, is het mogelijk pre-acties uit te voeren en post acties.

PHP:

<?php 

class DatabaseFilter extends Filter {
    
    function execute (&$filterChain)
    {
        // open database
        
        $filterChain->execute();    
        
        // close database
    }
    
}

?>

Heb je hier wat aan?

[JKVA]

Michali noemde al kort de naam servicelaag. Dit is zeker een concept waar je naar kunt kijken. Hierin staat de kern van je applicatie vastgelegd en worden applicatiespecifieke zaken afgehandeld. Je domeinklassen blijven zo "schoon" van specifieke code en zijn daardoor beter herbruikbaar voor bijvoorbeeld andere projecten.

Bovendien krijg je zo kleinere klassen en methoden, omdat aan de ene kant niet elk detail van een domeinklasse in de flow hoeft te worden geprogrammeerd, aan de andere kant hoef je geen complexe code in je domeinklassen te plaatsen.

Ik werk met Java, maar dit is volgens mij met PHP ook prima te realiseren.

[AtlonXP1800]

bedankt voor alle reacties, het plaatje van rapture ziet er erg duidelijk uit, ik zat een laag te veel te denken volgens mij (dacht dat de db nog onder de data laag kwam)

Alleen hoe plaats je dataobjecten in dit model? een dataobject is een object, gebaseerd op een database tabel.

simpel voorbeeldje:

PHP:

<?php
/**
 * Table Definition for user
 */
require_once 'DB/DataObject.php';

class DataObjects_User extends DB_DataObject 
{
    ###START_AUTOCODE

    /* the code below is auto generated do not remove the above tag */
    var $__table = 'user';       // table name
    var $user_Id;                // int(11)  not_null primary_key auto_increment
    var $first_Name;             // string(30)  not_null
    var $last_Name;              // string(40)  not_null
    var $email;                  // string(100)  not_null

    /* Static get */
    function staticGet($k,$v=NULL) {
        return DB_DataObject::staticGet('DataObjects_User',$k,$v);
    }

    /* the code above is auto generated do not remove the tag below */
    ###END_AUTOCODE
}
?>

handige hiervan is dat je tegen een instantie van het object kan zeggen object->get(1) zodat het object gevuld word met het record met primary key 1 uit de database. (geen sql & php menging nodig dus)
alleen is dit dan meteen ook mijn domeinobject, en hoort het thuis in de logic tier? (je kan de klasse nutuurlijk uitbreden met logica) of hoort het thuis in de data laag?

[Michali]

Als je een erg simpel model en weinig domein logica hebt, dan kan dit best goed werken. Dit heeft ook een naam, Active Record.

Als je model wat groter wordt, en je tabellen uiteindelijk niet meer goed aansluiten om je domein objecten, dan is het beter om je data access code te verplaatsen naar een aparte laag, die idd tussen je opslagmechanisme (meestal je DB) en je domein laag zit. Je domein laag en eventueel je GUI maakt daar dan gebruik van.

Je kunt het zelfs zo ontwerpen dat de interfaces voor die classes in je domein laag zitten (die vaak de naam Repository dragen) en dat de implementatie in een andere laag zit. Zo is je domein laag ook geheel losgekoppeld van de werkelijk implementatie van je data access code. Dat maakt het geheel wel wat complexer, maar geeft je wel wat meer ruimte.

Ik zou gewoon eens wat experimenteren met verschillende methoden. Je merkt dan vanzelf wel wat lekker werkt en wat niet. Ik kan je nu al vertellen dat het geen makkelijk onderwerp is en je zeker problemen kan verwachten.