[NHibernate] Read only properties in persistence class

[whoami]

Ik ben even met NHibernate aan het spelen.
Alles lukt, maar ik heb toch ff een vraagje.

Er zit me nl. iets een beetje dwars.

Stel, ik heb een class 'Persoon' die ik in de DB wil kunnen saven/ophalen/etc...

Die class Persoon, heeft, naast properties als 'Naam' (die zowel gettable als settable zijn), ook een property Id. Die property mapped met de primary key van de database-tabel.
Nu is het zo, dat ik die Id property liever read-only maak in m'n class. Dit vind ik netter. Niemand zou dat Id moeten kunnen wijzigen.
Echter, als ik gebruik maak van NHibernate, dan is het blijkbaar zo dat ieder 'field' in m'n class die ik wil persisten, getters en setters nodig heeft.
Die getters en setters hoeven niet perse public te zijn (met private setters/getters lukt het saven ook wel), maar in .NET heb je nu eenmaal de (duffe) beperking dat je setter en je getter dezelfde access modifier moeten hebben.

Wat ik dus wil, is dat ik het attribuut 'Id' van m'n persoon class wel wil kunnen opvragen, maar niet wil kunnen 'setten'. Iemand een idee hoe ik dit best kan aanpakken icm NHibernate ?
Blijkbaar kan ik ook niet mappen met 'fields' in m'n class, maar moeten het wel degelijk properties zijn.

Java heeft hier het voordeel dat je daar geen properties hebt, maar aparte getters/setters moet schrijven. Het voordeel daarvan is, dat je een private setter kunt maken en een public getter, maar in .NET lukt me dit blijkbaar niet.

Iemand ideeën ?

[whoami]

Hmm, ik kan natuurlijk wel een private property maken die zowel getters/setters heeft, en dan een public getId() method of een public PersonId property bv, die dan enkel een getter heeft....

Da's een mogelijkheid, maar zijn er geen 'elegantere' ?

[whoami]

Eh, ok:

Je kan dus blijkbaar ook in je mapping file opgeven dat hij direct naar het 'field' moet mappen:

code:

<id name="_id" column="customerId" access="field">

Gewoon ff verder lezen dus.

[Verwijderd]

whoami schreef op zaterdag 27 augustus 2005 @ 00:25:
Java heeft hier het voordeel dat je daar geen properties hebt, maar aparte getters/setters moet schrijven. Het voordeel daarvan is, dat je een private setter kunt maken en een public getter, maar in .NET lukt me dit blijkbaar niet.

FYI, nieuw in C# 2.0 is:

code:

  public property Foo 
  {
    get{ return this.foo; }
    private set{ this.foo = value; }
  }

[whoami]

Da's natuurlijk een hele verbetering.
Ik dacht dat ik ooit wel eens gelezen had, dat dit in 2.0 mogelijk ging zijn, maar ik wist het niet meer zeker.

[Eelke Spaak]

offtopic:
Waarom heeft C# eigenlijk dit type properties? Ik neem aan dat MS hier een weloverwogen keuze voor heeft gemaakt, gezien de algehele kwaliteit van C#, maar echt voordelen zie ik hier niet aan... Ik vergelijk het dan even met Java-style 'properties'.

[pjvandesande]

whoami schreef op zaterdag 27 augustus 2005 @ 00:25:
Java heeft hier het voordeel dat je daar geen properties hebt, maar aparte getters/setters moet schrijven. Het voordeel daarvan is, dat je een private setter kunt maken en een public getter, maar in .NET lukt me dit blijkbaar niet.

Je kunt in .NET natuurlijk ook gewoon aparte getters/setters maken in vorm van methods. Dus zoals in JAVA.

Ik zie het bij JAVA alleen maar als een nadeel.

[whoami]

questa schreef op zaterdag 27 augustus 2005 @ 11:12:
[...]


Je kunt in .NET natuurlijk ook gewoon aparte getters/setters maken in vorm van methods. Dus zoals in JAVA.

Jaha, weet ik wel, maar dat lukt afaik niet icm NHibernate.
Daar geef je nl. op welk field in je class mapped met welke column in je database.
Bij Hibernate (de Java versie dus), gaat Hibernate, als je niet specifieert dat het 'field' zelf moet ge-accessed worden, de get en set method van dat veld gaan zoeken.

[whoami]

Eelke Spaak schreef op zaterdag 27 augustus 2005 @ 11:11:

offtopic:
Waarom heeft C# eigenlijk dit type properties? Ik neem aan dat MS hier een weloverwogen keuze voor heeft gemaakt, gezien de algehele kwaliteit van C#, maar echt voordelen zie ik hier niet aan... Ik vergelijk het dan even met Java-style 'properties'.

Mja, ik weet het niet.
MIsschien was het wel niet zo 'weloverwogen', en hebben ze er gewoon niet aan gedacht ?

Uiteindelijk is het dus blijkbaar wel mogelijk in C# 2.0. Gelukkig maar.

[Verwijderd]

In Java kun je gewoon setters private maken, wellicht werkt dit ook voor .Net.

edit:
nevermind, mosterd na de maaltijd...

[ Voor 24% gewijzigd door Verwijderd op 27-08-2005 12:11 ]

[Verwijderd]

whoami schreef op zaterdag 27 augustus 2005 @ 11:20:
[...]

Mja, ik weet het niet.
MIsschien was het wel niet zo 'weloverwogen', en hebben ze er gewoon niet aan gedacht ?

Uiteindelijk is het dus blijkbaar wel mogelijk in C# 2.0. Gelukkig maar.

Ik denk dat jij hier doelt op het "vergeten" van verschillende visibility voor getters & setters en dat Eelke meer in het algemeen doelt op properties als taalconstruct vs. JavaBeans style properties.

Gezien de kennis en ervaring van Anders Hejlsberg en de rest van het C#/.NET team durf ik wel te speculeren dat het niet vergeten is maar dat de feature "gesneuveld' is in de eindeloze discussie over deadlines, kwaliteit en impact op andere onderdelen van het framework. Het is waarschijnlijk dat of een of andere taalpurist heeft per ongeluk een discussie gewonnen over dat verschillende access niveaus een teken zijn van slecht design van je class Maar goed, het is hoe dan ook opgelost in 2.0

Voor wat betreft de keuze van properties als taalconstruct: die valt in de categorie "syntactical sugar" waarin je ook de foreach statement, operator overloading, enums, attributen en wellicht ook generics kan scharen. C# heeft daarin een "zoetere" richting gekozen dan Java. Gezien de vele "verbeteringen" in Java 5 kun je denk ik wel stellen dat die designkeuze de juiste is geweest, ik denk echter dat het overboord gooien van JavaBeans in het kader van legacy applicaties als een te grote stap gezien werd. Plus het zou dan wel heel erg veel op elkaar zijn gaan lijken

[alienfruit]

Ik denk dat het een trukje van de Borland-er is, als je kijkt lijkt het namelijk verdomd veel op de Delphi manier. Maar dan op een andere plek