Business logic / Data layer scheiding

[ReverendBizarre]

Ik werk op dit moment voor mijn afstudeerstage aan een intranet applicatie in PHP5/MySQL. Daarbinnen probeer ik zoveel mogenlijk een stricte scheiding te houden tussen de presentatie laag, de business logic laag en de data laag.

Wat ik me nou afvraag. Is het 'netjes' om vanuit je datalaag recordsets terug te geven aan je business laag? In principe zijn die recordsets gewoon veredelde associative arrays met wat methoden als fetchRow() en moveNext() eromheen. Dus wat dat betreft lijkt het mij niet zo verkeerd om ze gewoon direct te gebruiken ipv ze eerst te vertalen naar 'domain objects' (aangezien ik niet voor al mijn data van plan was om classes erbij te programmeren). Maar is dit nou netjes of is dit eigenlijk 'not done' in een 3-tier applicatie? De daadwerkelijke database queries zouden nogsteeds strict gescheiden zijn van de business logic, alleen loopt de business logic dus wel direct te interfacen met recordsets dus is de database niet volledig transparant voor de business layer.

[Gonadan]

IrishMaiden schreef op maandag 10 april 2006 @ 12:02:
Ik werk op dit moment voor mijn afstudeerstage aan een intranet applicatie in PHP5/MySQL. Daarbinnen probeer ik zoveel mogenlijk een stricte scheiding te houden tussen de presentatie laag, de business logic laag en de data laag.

Wat ik me nou afvraag. Is het 'netjes' om vanuit je datalaag recordsets terug te geven aan je business laag? In principe zijn die recordsets gewoon veredelde associative arrays met wat methoden als fetchRow() en moveNext() eromheen. Dus wat dat betreft lijkt het mij niet zo verkeerd om ze gewoon direct te gebruiken ipv ze eerst te vertalen naar 'domain objects' (aangezien ik niet voor al mijn data van plan was om classes erbij te programmeren). Maar is dit nou netjes of is dit eigenlijk 'not done' in een 3-tier applicatie? De daadwerkelijke database queries zouden nogsteeds strict gescheiden zijn van de business logic, alleen loopt de business logic dus wel direct te interfacen met recordsets dus is de database niet volledig transparant voor de business layer.

Dat is persoonlijk.
Ik vind het niet netjes omdat ik de businessLogic altijd alleen maar met de 'objecten' van het programma zelf wil laten werken. De datalaag zorgt voor de omzetting van en naar de database.

Maar als jou dat niet zo boeit dan kan je ze lekker doorgooien, als is je scheiding dan wel minder sterk

[MicroWhale]

denk je data-laag eens helemaal weg en kijk eens goed naar je business-logic laag en kijk eens goed naar de huidige interfacing:

Hoe wil je er het liefst informatie uithalen?
Is dit de meest optimale manier voor de gebruiker (van de laag)?
Kan het op andere manieren?
Wat is het doel van elke informatie-aanvraag en wordt deze logisch gepresenteerd?
Zijn er toekomstige veranderingen waar ik rekening mee kan houden? (is de opzet flexibel en uitbreidbaar?)
etc... Er zijn nog wel wat vragen te bedenken....

En dit kun je in principe bij elke laag doen natuurlijk.

[ReverendBizarre]

Ja daar zit ik dus ook mee. Aan de ene kant lijkt het me niet een enorme ramp maar de perfectionist/systeemarchitect in mij vindt het toch niet netjes.

Ookal heb ik wel mijn eigen abstractie laag om de data laag heengebouwd dus de recordsets zijn door mijzelf gemaakt en de interface wordt door mij beheerd (het is nu een 1:1 mapping op alle ADORercordSet methoden die ik zelf nuttig vindt, maar in de toekomst zou dat dus kunnen veranderen zonder dat de rest van mijn applicatie daar last van zou hebben).

De voornaamste reden dat ik hiermee zit is dan ook niet luiheid, maar meer het feit dat ik nogal erg OO bezig ben in PHP (ik ben eigenlijk een C++/Java programmeur) en ik toch steeds bang blijf dat uiteindelijk de performance door al mijn OO structuur en abstractie lagen misschien eronder gaat leiden. Direct de recordsets gebruiken is een stuk sneller dan eerst tig objecten moeten instantieren. Maar misschien maakt het uiteindelijk kwa performance niet zo veel uit. Ik weet het gewoon niet. Trade offs, trade offs... zo moeilijk! :\