Momenteel ben ik een beetje bezig met het instuderen van Fowler's Enterprise Patterns, namelijk TableModule en TableDataGateway.
Volgens Fowler zouden deze patterns zeer goed moeten samenwerken met elkaar en met het .NET framework ( owv de beschikking over Datasets ).
TableModule is een pattern voor de Domain Logic (Business Logic) en
TableDataGateway is een pattern die op de Datasource layer thuishoort.
Als ik het goed snap, zouden deze patterns op de volgende manier moeten samenwerken met elkaar:
TableDataGateway
Voor iedere tabel in uw database heb je een 'Gateway'-class. In deze class zitten de methods om records om inserts, update, deletes en selects uit te voeren op de betreffende tabel.
Iedere method kan een Dataset teruggeven ( ik gebruik het .NET framework voor mijn applicatie, dus dit kan ik gebruiken).
TableModule
Dit pattern wordt gebruikt in de Bussiness Logic-layer.
Terug is er voor iedere tabel een dergelijke class (grofweg gezien).
Een instantie van een TableModule class wordt aangemaakt door middel van een Dataset. De Datatable in die dataset wordt dan gekopieerd naar een Datatable member in de TableModule-class.
Op deze Datatable-member kan dan de nodige bussiness-logic worden uitgevoerd en het resultaat wordt terug naar de GUI-layer teruggestuurd.
Relaties tussen de layers
1. De GUI-layer zal de Datasource-layer aanspreken en een Dataset (recordset) ontvangen.
2. De GUI-layer gebruikt deze Dataset om een instantie van een Tablemodule-class (bv: de class die hoort bij de 'users'-table )
3. Daarna kunnen methods op deze instantie uitgevoerd worden (bv: checkPassword() ).
Dit wilt dus zeggen dat, indien ik de werking van beide patterns wel goed snap, de GUI-layer afhankelijk is van de Datasource-layer en de Bussiness-Logic layer.
Ik dacht toch dat het principe van multi-tiered development wil zeggen dat de bovenste laag enkel kennis heeft van de laag eronder ? Maar volgens mij is dat nu toch niet het geval wanneer deze patterns samen worden gebruikt.
Misschien nog een citaat uit het PoEAA boek van Fowler
Volgens Fowler zouden deze patterns zeer goed moeten samenwerken met elkaar en met het .NET framework ( owv de beschikking over Datasets ).
TableModule is een pattern voor de Domain Logic (Business Logic) en
TableDataGateway is een pattern die op de Datasource layer thuishoort.
Als ik het goed snap, zouden deze patterns op de volgende manier moeten samenwerken met elkaar:
TableDataGateway
Voor iedere tabel in uw database heb je een 'Gateway'-class. In deze class zitten de methods om records om inserts, update, deletes en selects uit te voeren op de betreffende tabel.
Iedere method kan een Dataset teruggeven ( ik gebruik het .NET framework voor mijn applicatie, dus dit kan ik gebruiken).
TableModule
Dit pattern wordt gebruikt in de Bussiness Logic-layer.
Terug is er voor iedere tabel een dergelijke class (grofweg gezien).
Een instantie van een TableModule class wordt aangemaakt door middel van een Dataset. De Datatable in die dataset wordt dan gekopieerd naar een Datatable member in de TableModule-class.
Op deze Datatable-member kan dan de nodige bussiness-logic worden uitgevoerd en het resultaat wordt terug naar de GUI-layer teruggestuurd.
Relaties tussen de layers
1. De GUI-layer zal de Datasource-layer aanspreken en een Dataset (recordset) ontvangen.
2. De GUI-layer gebruikt deze Dataset om een instantie van een Tablemodule-class (bv: de class die hoort bij de 'users'-table )
3. Daarna kunnen methods op deze instantie uitgevoerd worden (bv: checkPassword() ).
Dit wilt dus zeggen dat, indien ik de werking van beide patterns wel goed snap, de GUI-layer afhankelijk is van de Datasource-layer en de Bussiness-Logic layer.
Ik dacht toch dat het principe van multi-tiered development wil zeggen dat de bovenste laag enkel kennis heeft van de laag eronder ? Maar volgens mij is dat nu toch niet het geval wanneer deze patterns samen worden gebruikt.
Misschien nog een citaat uit het PoEAA boek van Fowler
Table Data Gateway works particularly well with Table Module, where it produces a record set data structure for the Table Module to work on. Indeed, I can't really imagin any other database-mapping approach for Table Module.
I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. Where the fear has gone there will be nothing. Only I will remain.