[ALG]Patterns, Data Mapper combi met Data Gateway

Pagina: 1
Acties:

  • Scare360
  • Registratie: Juli 2001
  • Laatst online: 23-08 18:23
Graag wil het volgende wel eens ter discussie brengen:

Fowler geeft een hoop richtlijnen voor een Data Mapper. Over het algemeen komt het er op neer dat je dynamisch queries opmaakt. Met wat gehannes kun je die ook nog wel via stored procedures inpakken, maar in de voorbeelden in zijn boek is dat iig niet het geval. Jimmy Nilsson zegt: wat er ook gebeurt stored procedures kan en mag je niet laten liggen, or-mapping my ass, niet ten koste van performance.

Om het kort te houden... ik dacht zelf aan een Data Mapper met een Mapper per class, een Finder, Identity Map, eventueel een Registry om Lazy Load in te passen MAAR met als grote verschil een Data laag d'r achter met een DataGateway pattern. De LLBLGen zou een redelijk flexibele data laag kunnen leveren, met eventueel een query runner d'r langs voor "exceptionele" gevallen.

Iemand een mening? Iemand voostellen voor een laagje framework over de LLBLGen klassen heen om een OR-Mapping laagje te bewerkstelligen?

  • whoami
  • Registratie: December 2000
  • Laatst online: 23:02
[nohtml]
paulgielens schreef op 07 March 2003 @ 15:33:
Graag wil het volgende wel eens ter discussie brengen:

Fowler geeft een hoop richtlijnen voor een Data Mapper. Over het algemeen komt het er op neer dat je dynamisch queries opmaakt. Met wat gehannes kun je die ook nog wel via stored procedures inpakken, maar in de voorbeelden in zijn boek is dat iig niet het geval. Jimmy Nilsson zegt: wat er ook gebeurt stored procedures kan en mag je niet laten liggen, or-mapping my ass, niet ten koste van performance.
SP's moet je zowiezo gebruiken, niet alleen om performance doeleinden, maar ook om veiligheidsoverwegingen.

https://fgheysels.github.io/


  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024

Alarmnummer

-= Tja =-

Ik zie niet in waarom je dynamisch queries aan moet maken. Als je een specifieke mapper gaat maken, dan weet je dus exact wat je gaat querien, dus dan kan het ook een stored procedure maken. Als je geen specifieke mapper gaat maken, dan valt er altijd nog wel een mouw aan te passen, zie bv QueryObject. Je zou daar ook en stored procedure aanroep in kunnen wrappen.

  • Scare360
  • Registratie: Juli 2001
  • Laatst online: 23-08 18:23
Stored procedures zijn toch echt wel iets minder dynamisch dan... Ik praat dus specifiek over een DataGateway pattern, en of deze toepasbaar is en anders waarom niet, eventuele voor een tegens of betere oplossingen?

Afbeeldingslocatie: http://www.connexx.nl/pub/plaatje.gif

Grafische ondersteuning dan maar. De LLBLGen gooit al een SelectOne, SelectAll, Select op basis van FK's, relatie met mogelijke kinderen is dus ook te realiseren. Een combinatie van RowDataGateway & TableDataGateway. Als ik er zo naar kijk zou een uitbreiding van de LLBLGen zelfs mogelijk zijn, door EntityObject(s) te genereren voor iedere tabel, associaties zijn te vinden door de FK's en automatisch daarop ref in het betreffende EntityObject te leggen naar een Collection.

ps: De complexiteit van een QueryObject doet mij besluiten deze al links te laten liggen, een scanner/parser d'r voor schrijven zie ik ff niet zitten.

[ Voor 16% gewijzigd door Scare360 op 08-03-2003 08:42 ]