[.Net/OR-mapping] Hoe beslissen wat te mappen?

[zoepercavia]

Ik ben al een tijdje bezig met een object-relational mapper en het begint al heel aardig op te schieten (inheritance, relaties, unit of work zit er nu in en lijkt het heel aardig te doen). Tegelijkertijd met de mapper heb ik een programma geschreven om de code voor de mapper automatisch te genereren. Ik liep eerst alles namelijk zelf in te tikken, maar dat is erg arbeidsintensief en foutgevoelig. Deze 'mappergenerator' werkt nu ook prima (hoewel de code van de generator zelf ERRUG lelijk is ).

De mappergenerator analyseert nu een assembly op domein objecten en genereert dan de collections, fieldindexen, mapper en relations. Binnen een domein object kijk ik nu naar alle private velden en die worden allemaal gemapt. Dat werkt wel, maar is natuurlijk niet handig als je private velden hebt die niet gemapt moeten worden.

Ik zat er aan te denken om op basis van attributes in de domein code de velden te selecteren die gemapt moeten worden. Dus bijvoorbeeld een attribute [Persistable] voor bij properties. Nu is mijn vraag aan jullie wat jullie daarvan vinden? Wordt het vaker zo gedaan?

Voordelen:
- domein laag programmeur kan zeer makkelijk aangeven wat te mappen (maar hij kan het ook vergeten)
- mapper blijft in sync met domein laag

Nadelen:
- domein code wordt vervuild met persistence zaken

Andere mogelijkheden:
- Met behulp van een GUI de velden en relaties selecteren, daar heb ik echter de kennis en de tijd niet voor

Misschien jullie nog andere ideeen?

[whoami]

zoepercavia schreef op 10 August 2003 @ 18:02:
Ik zat er aan te denken om op basis van attributes in de domein code de velden te selecteren die gemapt moeten worden. Dus bijvoorbeeld een attribute [Persistable] voor bij properties. Nu is mijn vraag aan jullie wat jullie daarvan vinden? Wordt het vaker zo gedaan?

Ja, dat kan je doen. Ik heb ooit eens een artikel gelezen waar diezelfde methode min of meer toegepast werd in ASP.NET.
Daar werd ook dmv (custom)attributes aangeven welke variabelen er in de state moesten bewaard worden.
Ziehier bijhorend topic:
[rml][ .NET] State in ASP.NET bewaren adhv Reflection en Attribute[/rml]

[ Voor 4% gewijzigd door whoami op 10-08-2003 18:41 ]

[TlighT]

zoepercavia schreef op 10 August 2003 @ 18:02:
Ik zat er aan te denken om op basis van attributes in de domein code de velden te selecteren die gemapt moeten worden. Dus bijvoorbeeld een attribute [Persistable] voor bij properties. Nu is mijn vraag aan jullie wat jullie daarvan vinden? Wordt het vaker zo gedaan?

Ik gebruik momenteel Hibernate icm XDoclet, dat is dan wel Java maar het werkt op dezelfde manier als jij hierboven beschrijft.

Hoe staat het trouwens met MS ObjectSpaces, is er al iets meer bekend over wanneer ze dat klaar hebben?

[ Voor 9% gewijzigd door TlighT op 10-08-2003 19:53 ]

[alley]

Uit luiheid doe heb ik het in mijn versie precies andersom gedaan De attribute DoNotPersist toegevoegd, aangezien dat minder vaak voorkomt (maar bij mij zijn het dan ook de properties van een object die persistant zijn, niet de privates)

[EfBe]

Persistence mbv attributes == tijdrovend iets == groot nadeel.
EntityBroker gebruikt dit (nog) maar die gaan ook over op een andere mapping manier, via een XML file (ook erg intensief maar goed). Objectspaces van MS (.NET 1.2) gebruikt ook een XML file.

Je vraag is: wat te mappen, maar je praat niet over het mappen van fields / entities op entities in een persistent storage (database), waar het juist om gaat. Al het andere is geen mapping maar gewoon inheritence.

[EfBe]

TlighT schreef op 10 August 2003 @ 19:45:
Hoe staat het trouwens met MS ObjectSpaces, is er al iets meer bekend over wanneer ze dat klaar hebben?

Objectspaces zit in de volgende versie van .NET, die komt met de volgende versie van visual studio.net (2004), ergens in 2004, ik gok zelfop de 2e helft van 2004.

[zoepercavia]

alley schreef op 11 August 2003 @ 08:59:
Uit luiheid doe heb ik het in mijn versie precies andersom gedaan De attribute DoNotPersist toegevoegd, aangezien dat minder vaak voorkomt (maar bij mij zijn het dan ook de properties van een object die persistant zijn, niet de privates)

Ik ga ook voor de properties hoor . Ik had een beetje zonder na te denken de privates gebruikt voor de mapping omdat ik niet had verwacht dat m'n code generator zo snel bruikbaar zou zijn. Maar het was inderdaad gewoon een foute beslissing.

EfBe schreef op 11 August 2003 @ 09:04:
Persistence mbv attributes == tijdrovend iets == groot nadeel.
EntityBroker gebruikt dit (nog) maar die gaan ook over op een andere mapping manier, via een XML file (ook erg intensief maar goed). Objectspaces van MS (.NET 1.2) gebruikt ook een XML file.

Kan je misschien uitleggen waarom attributes arbeidsintensief zijn? Het is voor de programmeur toch juist erg makkelijk om snel aan te kunnen geven wat gemapped worden (of wat niet zoals Alley doet). Het idee van XDoclet om bij elke build de mapper te genereren spreekt me overigens ook wel erg aan. Alleen dan moet je nog iets verzinnen om de database up-to-date te houden.

EfBe schreef op 11 August 2003 @ 09:04:

Je vraag is: wat te mappen, maar je praat niet over het mappen van fields / entities op entities in een persistent storage (database), waar het juist om gaat. Al het andere is geen mapping maar gewoon inheritence.

Sorry, ik snap niet helemaal wat je bedoelt. Ik map inderdaad gewoon naar de database en snap niet echt wat dit met inheritance te maken heeft. Of bedoel je dat PersonMapper derived is van Person (en dus enkel een specialisatie)? Overigens zit ik ook niet echt goed in de entities.

[EfBe]

zoepercavia schreef op 11 augustus 2003 @ 10:40:
[...]
Kan je misschien uitleggen waarom attributes arbeidsintensief zijn? Het is voor de programmeur toch juist erg makkelijk om snel aan te kunnen geven wat gemapped worden (of wat niet zoals Alley doet). Het idee van XDoclet om bij elke build de mapper te genereren spreekt me overigens ook wel erg aan. Alleen dan moet je nog iets verzinnen om de database up-to-date te houden.

Nou, als je 100 tabellen hebt, dan is het erg arbeidsintensief om voor elke tabel de class te maken, de properties te mappen handmatig etc. Het is juist makkelijk als je die meteen kunt genereren met 2 muisklikken (dwz, voor alle tables ). Je moet anders alle mogelijke mappings zelf gaan intikken. Niet alleen tijdrovend (100tables a gem. 7 fields, is altijd nog 700 attributes toevoegen), maar ook foutgevoelig.

Sorry, ik snap niet helemaal wat je bedoelt. Ik map inderdaad gewoon naar de database en snap niet echt wat dit met inheritance te maken heeft. Of bedoel je dat PersonMapper derived is van Person (en dus enkel een specialisatie)? Overigens zit ik ook niet echt goed in de entities.

Nee ik bedoel dat je de entity (en dan bedoel ik Yourdon/Chen's definitie van entity, dwz de gangbare zoals ook wordt gehanteerd door DBA's/database designers, en niet Fowler's herdefinitie die kant noch wal raakt) zowel in class als tabelvorm terug vindt in je systeem, en dus bv praat over 'customer' zowel als tabel als als class. Je kunt dan in code wel inheritence gebruiken door bv een class van customer te deriven die specialisatie toevoegt aan customer, maar dat is in een relational model nauwelijks te modelleren, (zie Nijssen/Halpin Conceptual Schema and Relational Database design over subtypes/supertypes projecties op E/R model structuren in NIAM/ORM) en derhalve dus ook bv in een E/R model niet vaak zijn terug te vinden. (HET probleem voor O/R mappers die relational database models mappen op class structures).

Je inheritence die je eventueel ziet is specialisaties van de entity classes in code, maar niet in mapping, dus je inherited classes specialiseren je entity classes wel maar voegen geen mappings toe. Dit kan nl. niet, want zou je dat wel toestaan dan heb je een CLASS hierarchie opgebouwd aan de hand van VALUES in een bepaalde column, niet op basis van een relational model constructie als een (sequence van) foreign key(s).