[DESIGN] Inpassen onderdelen Three Tier

[Uiligheid]

Hola,

Ik neem aan dat er wel mensen zijn die bekend zijn met de three tier benadering. Ik wil een applicatie maken, die hier op gebaseerd is. Ik heb alleen een aantal vragen die ik in de literatuur en workshops op internet niet echt duidelijk benadert zie.

Mijn applicatie is opgedeeld in drie (duh..) lagen. De applicatielaag, de functielaag en de datalaag. Nu vroeg ik mij als eerste af: Moet de functielaag de transactie in elkaar vogelen en dan doorgeven aan de datalaag, of is de datalaag alleen verantwoordelijk voor het openen en sluiten van connecties en aanmaken van recordsets e.d.?

Mijn tweede vraag is: Ik maak gebruik van een dll, deze dll voert op een andere database transacties uit. Moet ik dit in het datalaag gedeelte zetten, of past deze dll beter in de functielaag? Hij valideert namelijk ook.

Je zou het natuurlijk ook zo kunnen zien:
----------------------------------------
Applicatielaag Interface
----------------------------------------
Functielaag (allerhande modulen)
Dll loopt parallel
Datalaag (allerhande modulen)
----------------------------------------

Dit zou dan inhouden dat in mijn design, de externe dll gezien moet worden als een parallel lopend design, en dat deze eigenlijk twee van de drie lagen in zich heeft.

Any opinions / views ??
Ik vind dit persoonlijk altijd wel leuke dingetjes om te doen, alleen je zit zo snel tegen de muren op te werken...

[Jelmer]

Antwoord 1:
De data laag weet hoe dingen moeten op worden geslagen. Zo kun je dus een datalaag hebben die met SQL werkt, maar net zo goed een interface-compatible datalaag die met XML oid werkt. Kortom, de SQL statements gaan in de datalaag.

antwoord 2:
Die dll is eigenlijk een extern programma, kortom die heeft weer een (presentatie-,) functie- en datalaag.

[Uiligheid]

Oke,
antwoord 2 ben ik het mee eens, behalve dat hij geen presentatielaag heeft, maar dat zien we even door de vingers dan

Antwoord 1 lijkt mij redelijk correct. Alleen je zit wel met het concept dat in de functielaag ook de validatie annex business rules moeten worden geimplementeerd. Dus ik vind het wel voorstelbaar dat de functielaag die SQL in elkaar ramt, maar mag het volgens mij niet zo zijn, dat de datalaag de SQL statements zelf maakt.
Is de oplossing dat deze dan moet worden doorgegeven van de functielaag, waarna de statement wordt uitgevoerd door de datalaag?

[Jelmer]

Als je de functie laag de sql statements laat maken, is het gewoon onmogelijk om op een eenvoudige manier er een andere datalaag onder te zetten. In de functielaag zitten idd je validaties en business rules. Neem even het volgende voorbeeld:
gui: user maakt nieuwe factuur aan en klikt op save
functie: checkt of alles klopt en geeft het Factuur object door aan de datalaag om op te slaan
data: ontvangt het Factuur object en slaat de data op in de data base

Hetzelfde voorbeeld allen nu wil de user ook nog printen:
gui: user klikt op print
funciie: checkt of alles klopt en geeft (andere) datalaag opdracht tot printen
data: ontvangt op dezelfde manier het Factuur object en zet de printer aan het werk.

Zoals je wel zult begrijpen is het in deze situatie noodzakelijk dat je functielaag dus GEEN sql 'kan', want waar heb je anders nog die data laag voor nodig?

Dit is trouwens wel een interresant pdf'je:
http://www.icim.fnt.hvu.nl/vak/ooad/2002%20Voorjaar/H5OOAD1/persistenceLayer.pdf
Op pagina 2 (in het bestand 4) staat het precies zoals het moet zijn (dat plaatje)

[Uiligheid]

dank je wel, dat is een mooi stukje literatuur.. Ik denk er zo wel uit te komen, anders laat ik het natuurlijk nog even horen...

[Uiligheid]

Ben nog wel even benieuwd over het een of ander trouwens. De bron hierboven gaat over OO. Maar ik ben helaas niet in gelegenheid om ook daadwerkelijk OO te gaan bouwen. Ook al zou ik er nu wel inzitten, dan kan ik mijn hele FO weer omgooien.

Nu is er een manier om nadat je de three tier indeling hebt gemaakt, modulen te definieren. Dit kan dan door het hoogste en laagste abstractieniveau van in een DFD neer te zetten.

Heeft iemand hier positieve of negatieve ervaringen mee? Het liefst zou ik een alternatief ervoor zien namelijk. Iemand hints tips of tricks?

[Uiligheid]

[daaguitmodus]
Of heeft niemand hier verstand van ontwerpen, maar alleen van syntax ?!
[/daaguitmodus]

oke, ik ben een beetje erg gebrand.. maar ik moet echt mijn moduultjes gaan definieren, en weet niet waar ik moet beginnen.. Oh. was het maar OO, dan had je dat heerlijke UML...

[Dennis]

Multi-Tier development is zo goed als onmogelijk zonder OO. En das gewoon een feit. Staat ook in een boek over PHP4.

Als je met Multi-Tier development gaat werken werk je met modulen. Modulen zijn eigenlijk al objecten als je ze gaat gebruiken. Hoe wil jij dit gaat inpassen? Wil je met allemaal includes gaan werken? Nee... dit gaat niet goed.

De webapplicatie in php waar ik zelf momenteel ook mee bezig ben is ook 100% OO en volledig Three-tiered. En dit kan makkelijk op die manier. Ik kan zo een andere class laten aanroepen (sterker nog, dit gebeurt al dynamisch) om met een andere database te laten samenwerken.

Verder zeg je zelf al dat je een foute implementatie hebt van je applicatie, namelijk dat je geen presentatielaag hebt. Lijkt me idd niet echt correct, want hoe wil je dan kunnen kiezen tussen verschillende documentuitvoersoorten

Verder concludeer ik een beetje dat je niet hebt nagedacht over je programma. Dat is helemaal niet erg, toen ik aan mn huidige project begon was ik ook zo stom om slechts gedeeltelijk een OO opzet te hanteren. Later heb ik besloten volledig OO te gaan programmeren in de applicatie.

Het zou voor jezelf handig zijn als je een opzet maakt met wat wil je dat je applicatie gaat doen, welke objecten ga je gebruiken, welke classes kun je hergebruiken en welke moet je zelf maken. Hoe communiceer je tussen de classes, gebruik je allemaal classes in elkaar of gebruik je gewoon verstandig XML.

Hoe is je output? Is dit ook XML? Gebruik je dat later om een interface om je programma heen te bouwen? Of zit dat al in één van de andere lagen? Als dat zo is bouw je ook niet three-tiered, want jij zou dan niet je applicatie snel geschikt kunnen maken voor makkelijke bestandsuitwisseling met een andere willekeurige applicatie.

Verder heb ik nog niet echt ontdekt welke programmeertaal je nou gebruikt

[Uiligheid]

Oke, leuk leuk leuk...

Ik heb wel degelijk nagedacht over mijn applicatie, ik ben in het ontwerp inmiddels al op 250 kantjes aan beschrijvingen.. Maar dat terzijde.

In ieder geval:

1. Multi Tier (in dit geval 3tier) is bijzonder goed te gebruiken zonder OO. Sterker nog, volgens mij bestond het al voor OO en is het juist een methode om procedureel programmeren in eerste instantie te ondersteunen. Dus imho is dit dus zeer bruikbaar. Van vroeger uit was het een methode om client-server applicaties aan te sturen, met een presentatie laag, een clientlaag en een serverlaag. Deze kan echter ook lokaal opgedeeld worden in een datalaag, een functielaag en een applicatie laag (zie ook de link in een post hierboven, die was heel leerzaam)
Zie trouwens ook: Klassieke en Objecgeorienteerde Systeemontwikkeling van Stephen R. Shach. Hierin staat dit ook als een soort van model van actiegeorienteerd programmeren. Maar verder doet het er ook niet toe.


2. De taal die ik bezig is VB

3. Ik heb wel een presentatielaag. Misschien staat dit er alleen een beetje verwarrend. Ik post hier echter niet mijn volledige ontwerp, alleen mijn problemen met gedeeltes van het ontwerp. Het ontwerp probleempje wat ik dus nu heb, is dat ik niet met een methode kan achterhalen wat de modulen nu moeten worden, en daar is mijn vraag voor. De interactie tussen presentatie en functielaag zit wel snor. De interactie tussen functielaag en datalaag ook wel, alleen de definitie van de modulen is mij niet volledig duidelijk.
Voorbeeldje:
Ik werk met data die naar twee databases moet, en die ook via twee verschillende methodes benadert moeten worden. Moet ik de module opdelen in de databases die benadert worden, of moet ik een opdeling maken in type benadering?