[O/R mapping]Ervaringen NHibernate *

[zneek]

Ik vroeg me af of er al iemand met NHibernate ge-experimenteerd heeft?

We gebruiken nu LLBLGenPro in .net projecten en dat bevalt op zich best, overigens een tool van gewaarde collega GoTter EfBe

NHibernate is een .Net port van Hibernate. In Java projecten prefereren we hibernate boven bijv EJB CMP. Ik zou het op zich wel prettig vinden om bij beide technieken dezelfde O/R mapper te kunnen gebruiken. Nu is NHibernate in alpha (0.3.0.0) en ik twijfel een beetje of er al iets zinnigs mee te doen is. Het kleine beetje documentatie wat er is doet me denken van wel, maar ik ben nog niet overtuigd.

Dus, heeft er al iemand mee gespeeld? En is het interessant om al eens projectje te doen gebruik makende van NHibernate?

[edit] Zou een modje de titel willen wijzigen in "[O/R mapping]Ervaringen NHibernate", thnx

[edit2] thnx modje

[ Voor 10% gewijzigd door zneek op 25-10-2004 19:52 ]

[tijn]

zneek schreef op 25 oktober 2004 @ 17:24:
Dus, heeft er al iemand mee gespeeld? En is het interessant om al eens projectje te doen gebruik makende van NHibernate?

Yep, en het bevalt me wel moet ik zeggen. Nou is het wel behoorlijk afhankelijk van de programmeerfilosofie die je hanteert. Als je gewoonlijk uitgaat van je database model en daar je applicatie op baseert ben je veel beter af met LLBLGen Pro. Ga je echter uit van een object georienteerd ontwerp en baseer je daar je datamodel op, dan is NHibernate een serieuze optie, mits je rekening houdt met de beperkingen van de huidige versie zoals ze ook in de FAQ vermeld staan. Het grootste gemis is momenteel lazy-load van many-one en one-one relaties. Hier wordt aan gewerkt (er is een CVS branch waar het wel in zit) maar het is nog niet klaar.
Ik zou zeggen probeer het gewoon. De bulk van de functionaliteit werkt feilloos.

Overigens kun je ook dit draadje lezen. Hier worden een aantal zeer zinnige (en ook onzinnige ) dingen gezegd over O/R mappers.

[zneek]

tijn schreef op 25 oktober 2004 @ 18:00:
[...]

Yep, en het bevalt me wel moet ik zeggen. Nou is het wel behoorlijk afhankelijk van de programmeerfilosofie die je hanteert. Als je gewoonlijk uitgaat van je database model en daar je applicatie op baseert ben je veel beter af met LLBLGen Pro. Ga je echter uit van een object georienteerd ontwerp en baseer je daar je datamodel op, dan is NHibernate een serieuze optie, mits je rekening houdt met de beperkingen van de huidige versie zoals ze ook in de FAQ vermeld staan. Het grootste gemis is momenteel lazy-load van many-one en one-one relaties. Hier wordt aan gewerkt (er is een CVS branch waar het wel in zit) maar het is nog niet klaar.
Ik zou zeggen probeer het gewoon. De bulk van de functionaliteit werkt feilloos.

Overigens kun je ook dit draadje lezen. Hier worden een aantal zeer zinnige (en ook onzinnige ) dingen gezegd over O/R mappers.

Interessante thread op asp.net. Flamewar tussen .net o/r mapper bouwers

Dat lazy load verhaal vind ik nog niet eens zo spannend, dus dat zou op zich geen reden zijn om het niet te doen.

[EfBe]

zneek schreef op 25 oktober 2004 @ 20:01:
Interessante thread op asp.net. Flamewar tussen .net o/r mapper bouwers

Naah, niet echt een flamewar, alleen die gast van DataObjects.net moet niet een nummerspelletje starten om te laten zien dat hij erg populair is en dan, wanneer hij wordt afgedroogd met dubbele cijfers ineens heel iets anders gaan aanhalen

Over nhibernate.
Mensen die nu gaan zeuren dat ik bevooroordeeld ben omdat ik in de O/R mapper business zit: dat zal best, maar ik weet er tegelijkertijd ook weer wat meer vanaf . Overigens zie ik nhibernate niet als concurrent.

Ik heb 2 uur gespendeerd een maandje terug ong om de source te bekijken. Ik moet zeggen, er is veel code, maar wat ik zag was 1 grote chaos. Niet alleen zit de code stikvol met "What does this code do?" (hoe kan dat nou, een programmeur die niet snapt wat zn eigen code doet? (jaja het is een port)), het is ook chaotisch opgezet: je kunt nauwelijks zaken terugvinden, de organisatie is ver te zoeken. Alle comments van hibernate (de javadoc comments) zijn gestript, wat ik dus een blunder van de 1e orde vind. Ook herkende ik werkelijk NIETS. Behalve inheritance ondersteunt llblgen pro's engine bv meer features dan nhibernate, maar ik herkende echt nauwelijks logica in de engine zo van "oh ja dit doet dat", echt bizar. Wellicht kwam het omdat alles erg gefragmenteerd is geimplementeerd: om alle classes die sql genereren te verzamelen ben je wel even zoet.

Nu zal men uiteraard zeggen: "het werkt wel!", maar dat is maar de vraag. Wat werkt zijn de unittest situaties. Een O/R mapper, zeker een die meerdere databases ondersteunt, is zo complex, dat je erg goed je best moet doen om het allemaal wat bugfree te krijgen, omdat je inmens veel functionaliteit hebt die je in allerlei contexts kunt gebruiken en het dan weer om kan vallen. Omdat 1) de code chaotisch is en 2) de programmeurs die het porten niet echt blijk geven van het doorhebben van hoe het allemaal werkt intern, is het nog maar de vraag of bugs echt worden opgelost en of nieuwe features echt goed worden geimplementeerd. Vergeet ook niet dat hibernate java specifieke zaken gebruikt die op .NET niet mogelijk zijn. (zoals cross-appdomain object awareness)

Ik erger me zolangzamerhand steeds meer aan de hype rondom nhibernate, die puur gebaseerd is op de faam van hibernate, niet op bewezen solide code en robuustheid. Hibernate is een solide O/R mapper waar erg veel werk in zit en dat zie er ook aan af. NHibernate is op dit moment een slappe port vol gaten die die faam nog lang niet heeft waargemaakt, het zou prettig zijn als de credits voor hibernate niet direct naar nhibernate vloeien.

Wil je nhibernate in een productieomgeving inzetten, dan wens ik je veel succes maar realiseer je wel welke risico's je neemt.

[ Voor 8% gewijzigd door EfBe op 25-10-2004 21:14 ]

[JaQ]

EfBe schreef op 25 oktober 2004 @ 21:11:
[...]

<snip>

Nu zal men uiteraard zeggen: "het werkt wel!", maar dat is maar de vraag. Wat werkt zijn de unittest situaties. Een O/R mapper, zeker een die meerdere databases ondersteunt, is zo complex, dat je erg goed je best moet doen om het allemaal wat bugfree te krijgen, omdat je inmens veel functionaliteit hebt die je in allerlei contexts kunt gebruiken en het dan weer om kan vallen.

<snip>

[frustratie]

probeer maar eens een dataset van meer dan 50 rijen uit een oracle database te sorteren.....

[/frustratie

[zneek]

EfBe schreef op 25 oktober 2004 @ 21:11:
[...]

Naah, niet echt een flamewar, alleen die gast van DataObjects.net moet niet een nummerspelletje starten om te laten zien dat hij erg populair is en dan, wanneer hij wordt afgedroogd met dubbele cijfers ineens heel iets anders gaan aanhalen

Over nhibernate.
Mensen die nu gaan zeuren dat ik bevooroordeeld ben omdat ik in de O/R mapper business zit: dat zal best, maar ik weet er tegelijkertijd ook weer wat meer vanaf . Overigens zie ik nhibernate niet als concurrent.

Precies, ik hoopte al op een reactie van je

Ik heb 2 uur gespendeerd een maandje terug ong om de source te bekijken. Ik moet zeggen, er is veel code, maar wat ik zag was 1 grote chaos. Niet alleen zit de code stikvol met "What does this code do?" (hoe kan dat nou, een programmeur die niet snapt wat zn eigen code doet? (jaja het is een port)), het is ook chaotisch opgezet: je kunt nauwelijks zaken terugvinden, de organisatie is ver te zoeken. Alle comments van hibernate (de javadoc comments) zijn gestript, wat ik dus een blunder van de 1e orde vind. Ook herkende ik werkelijk NIETS. Behalve inheritance ondersteunt llblgen pro's engine bv meer features dan nhibernate, maar ik herkende echt nauwelijks logica in de engine zo van "oh ja dit doet dat", echt bizar. Wellicht kwam het omdat alles erg gefragmenteerd is geimplementeerd: om alle classes die sql genereren te verzamelen ben je wel even zoet.

Nu zal men uiteraard zeggen: "het werkt wel!", maar dat is maar de vraag. Wat werkt zijn de unittest situaties. Een O/R mapper, zeker een die meerdere databases ondersteunt, is zo complex, dat je erg goed je best moet doen om het allemaal wat bugfree te krijgen, omdat je inmens veel functionaliteit hebt die je in allerlei contexts kunt gebruiken en het dan weer om kan vallen. Omdat 1) de code chaotisch is en 2) de programmeurs die het porten niet echt blijk geven van het doorhebben van hoe het allemaal werkt intern, is het nog maar de vraag of bugs echt worden opgelost en of nieuwe features echt goed worden geimplementeerd. Vergeet ook niet dat hibernate java specifieke zaken gebruikt die op .NET niet mogelijk zijn. (zoals cross-appdomain object awareness)

Ik erger me zolangzamerhand steeds meer aan de hype rondom nhibernate, die puur gebaseerd is op de faam van hibernate, niet op bewezen solide code en robuustheid. Hibernate is een solide O/R mapper waar erg veel werk in zit en dat zie er ook aan af. NHibernate is op dit moment een slappe port vol gaten die die faam nog lang niet heeft waargemaakt, het zou prettig zijn als de credits voor hibernate niet direct naar nhibernate vloeien.

Wil je nhibernate in een productieomgeving inzetten, dan wens ik je veel succes maar realiseer je wel welke risico's je neemt.

Dat is precies wat ik bedoel. Hibernate is onovertroffen, nofi naar LLBLGen uiteraard

Maar met MHibernate weet ik het nog zo net niet. Asl je Hibernate bekijkt zie je nogal wat afhankelijkheden naar andere "grote" opensource projecten. Als NHibernate een 100% port is hoop ik toch voor ze dat .net goede equivalenten voor die opensource componenten heeft.

Zo liepen wij ooit tegen de commons BeanUtils aan. Supermakkelijk in gebruik in Java, met heel weinig werk complexe objecten invullen vanuit een HttpRequest. Voor ons .net platform hebben we zelf maar iets gebouwd, wat wel werkt, maar nog niet in de schaduw van commons beanutils mag staan.

Dat is dan ook direct de hoofdreden dat ik NHibernate niet helemaal vertrouw, teveel zaken moeten omgebouwd/opnieuw gebouwd worden.

En tjah, als EfBe zegt dat het niet goed is, wie ben ik dan om het daarin niet te geloven

[disclaimer] ZneeK is betalende klant van EfBe, altijd vriendjes blijven met je leveranciers

[tijn]

EfBe schreef op 25 oktober 2004 @ 21:11:
[...]
Nu zal men uiteraard zeggen: "het werkt wel!", maar dat is maar de vraag. Wat werkt zijn de unittest situaties.

Mja, maar daarnaast heb ik ook een CMS omgebouwd naar NHibernate waarin eigenlijk geen workarounds nodig waren omdat iets niet werkte zoals ik het wilde.

Eigenlijk was NHibernate een soort van laatste strohalm omdat ik het vanwege de status nog niet zag zitten. Toen ik het uiteindelijk na een aantal andere toch maar es probeerde klopte alles precies. Eindelijk eens een O/R mapper voor .NET die doet wat ik wil in plaats van dat je de hele tijd je code loopt te verbouwen vanwege ontbrekende features of obscure bugs.

Ik erger me zolangzamerhand steeds meer aan de hype rondom nhibernate, die puur gebaseerd is op de faam van hibernate, niet op bewezen solide code en robuustheid. Hibernate is een solide O/R mapper waar erg veel werk in zit en dat zie er ook aan af. NHibernate is op dit moment een slappe port vol gaten die die faam nog lang niet heeft waargemaakt

Het was ooit een slappe port maar sinds een half jaar ofzo is het niveau gruwelijk omhoog gegaan waardoor het goed bruikbaar is geworden. Ik geloof trouwens graag dat het niveau nog niet op dat van het origineel ligt of op het niveau van andere java oplossingen, maar vind maar eens alternatieven voor .NET.

het zou prettig zijn als de credits voor hibernate niet direct naar nhibernate vloeien.

Mee eens, ik baseer mijn enthousiasme puur op eigen ervaringen en niet op de status van hibernate

Wil je nhibernate in een productieomgeving inzetten, dan wens ik je veel succes maar realiseer je wel welke risico's je neemt.

Ook mee eens, maar iedereen moet ook beseffen dat het risico bij vergelijkbare O/R mappers (en dan bedoel ik niet LLBLGen Pro want die werkt vanuit een fundamenteel andere invalshoek) net zo hoog ligt. Ik ben bugs tegengekomen in andere (commerciele) O/R mappers waar de honden geen brood van lusten en die regelrechte showstoppers voor een project waren (en zijn).

[ Voor 6% gewijzigd door tijn op 26-10-2004 01:02 ]

[Alarmnummer]

Ik had begrepen dat in .NET 2.0 een heel nieuw systeem zou zitten voor OR-mapping. Hoe verhoud dat zich tot lblgen, hibernate en andere OR-mappers?

[P_de_B]

zneek schreef op 25 oktober 2004 @ 23:54:
[...]

[disclaimer] ZneeK is betalende klant van EfBe, altijd vriendjes blijven met je leveranciers

Moeten leveranciers juist geen vriendjes blijven met hun klanten

Ik had begrepen dat in .NET 2.0 een heel nieuw systeem zou zitten voor OR-mapping. Hoe verhoud dat zich tot lblgen, hibernate en andere OR-mappers?

Objectspaces denk ik. Het laatste wat ik heb begrepen is dat het eerst komt te vervallen. Het zal nu in 2007 of zo deel uit gaan maken van (het ook uitgestelde) WinFS. Voorlopig nog niet dus.

[ Voor 8% gewijzigd door P_de_B op 26-10-2004 08:43 ]

[EfBe]

DrFrankenstoner schreef op 25 oktober 2004 @ 23:51:
[frustratie]
probeer maar eens een dataset van meer dan 50 rijen uit een oracle database te sorteren.....
[/frustratie

dataview's sort?

zneek schreef op 25 oktober 2004 @ 23:54:
Maar met MHibernate weet ik het nog zo net niet. Asl je Hibernate bekijkt zie je nogal wat afhankelijkheden naar andere "grote" opensource projecten. Als NHibernate een 100% port is hoop ik toch voor ze dat .net goede equivalenten voor die opensource componenten heeft.

NHibernate heeft sowieso het nadeel dat er op .NET geen application servers zijn, dus dat het terug moet vallen op wat MS aanbiedt in bv enterprise services. Verder is AspectJ veel verder dan de C# variant en weet ik niet echt of het uberhaupt wel gaat lukken op .NET omdat bytecode mangling op .NET wordt afgeraden.

En tjah, als EfBe zegt dat het niet goed is, wie ben ik dan om het daarin niet te geloven
[disclaimer] ZneeK is betalende klant van EfBe, altijd vriendjes blijven met je leveranciers

Jij mag roepen wat je wilt hoor

tijn schreef op 26 oktober 2004 @ 00:50:
Mja, maar daarnaast heb ik ook een CMS omgebouwd naar NHibernate waarin eigenlijk geen workarounds nodig waren omdat iets niet werkte zoals ik het wilde.

Valt me mee, serieus, omdat de code echt niet bijster goed in elkaar zit (erg belabberd eigenlijk). Verre van productiekwaliteit, ik zou dit soort code echt niet durven verkopen.

Eigenlijk was NHibernate een soort van laatste strohalm omdat ik het vanwege de status nog niet zag zitten. Toen ik het uiteindelijk na een aantal andere toch maar es probeerde klopte alles precies. Eindelijk eens een O/R mapper voor .NET die doet wat ik wil in plaats van dat je de hele tijd je code loopt te verbouwen vanwege ontbrekende features of obscure bugs.

Als je een gratis mapper wilt dan heb je op .NET niet zoveel keus inderdaad. Behalve Gentle.net en neo zijn ze allemaal niet bijster solide.

Het was ooit een slappe port maar sinds een half jaar ofzo is het niveau gruwelijk omhoog gegaan waardoor het goed bruikbaar is geworden. Ik geloof trouwens graag dat het niveau nog niet op dat van het origineel ligt of op het niveau van andere java oplossingen, maar vind maar eens alternatieven voor .NET.

Die zijn er genoeg hoor, maar toegegeven die kosten wel geld. Als je puur domain driven bezig wilt zijn, kun je bv kijken naar entitybroker. Moet je wel Thomas voor lief nemen, maar ach, dat valt op zich wel mee

Ook mee eens, maar iedereen moet ook beseffen dat het risico bij vergelijkbare O/R mappers (en dan bedoel ik niet LLBLGen Pro want die werkt vanuit een fundamenteel andere invalshoek) net zo hoog ligt. Ik ben bugs tegengekomen in andere (commerciele) O/R mappers waar de honden geen brood van lusten en die regelrechte showstoppers voor een project waren (en zijn).

Je wilt daar vast geen voorbeelden van noemen of wel ?

[tijn]

EfBe schreef op 26 oktober 2004 @ 09:41:
[...]
NHibernate heeft sowieso het nadeel dat er op .NET geen application servers zijn, dus dat het terug moet vallen op wat MS aanbiedt in bv enterprise services. Verder is AspectJ veel verder dan de C# variant en weet ik niet echt of het uberhaupt wel gaat lukken op .NET omdat bytecode mangling op .NET wordt afgeraden.

Dat Aspect# gebeuren werkt niet met bytecode aanpassing maar met code generatie meen ik, maar pin me daar niet op vast. Overigens hebben ze net een behoorlijk fundamentele wijziging doorgevoerd waardoor het proxy-gedeelte van NHibernate ook weer op de schop kan .

Valt me mee, serieus, omdat de code echt niet bijster goed in elkaar zit (erg belabberd eigenlijk). Verre van productiekwaliteit, ik zou dit soort code echt niet durven verkopen.

Nounou, zo belabberd is het ook weer niet. Complex en niet al te overzichtelijk, dat wel .

Als je een gratis mapper wilt dan heb je op .NET niet zoveel keus inderdaad. Behalve Gentle.net en neo zijn ze allemaal niet bijster solide.

En ook Gentle heeft me tot bijna wanhoop gedreven. Solide misschien, maar het kan zo weinig en het werkt onhandig.

Die zijn er genoeg hoor, maar toegegeven die kosten wel geld. Als je puur domain driven bezig wilt zijn, kun je bv kijken naar entitybroker. Moet je wel Thomas voor lief nemen, maar ach, dat valt op zich wel mee

Tja, entitybroker... Ik had al lang klant kunnen zijn. Helaas gooit Thomas zijn eigen glazen in door maar niet met een stabiele release te komen en in plaats daarvan bergen nieuwe features implementeert die misschien 1 klant van em nodig heeft. Zijn forumgedrag is hoogst amusant, maar marketingtechnisch is het niet zo slim

Je wilt daar vast geen voorbeelden van noemen of wel ?

Bij een niet nader te noemen O/R mapper werden in een foreach objecten verwijderd uit de collectie waarover geloopt werd. Ach ja, als inserts en updates werken dan zal deleten ongetwijfeld ook goed gaan en hoeven we het niet te testen

[EfBe]

tijn schreef op 26 oktober 2004 @ 10:29:
Dat Aspect# gebeuren werkt niet met bytecode aanpassing maar met code generatie meen ik, maar pin me daar niet op vast. Overigens hebben ze net een behoorlijk fundamentele wijziging doorgevoerd waardoor het proxy-gedeelte van NHibernate ook weer op de schop kan .

Op zich is het wel vooruitstrevend om AOP te gebruiken in een O/R mapper. Heb er een tijdje geleden ook over zitten denken voor een volgende versie ergens volgend jaar, maar vond dat de tools voor .NET en AOP nog dermate prematuur waren dat ik het maar heb laten varen.

Ik denk wel dat in de toekomst we er niet omheen kunnen, AOP, zeker in de wat lagere lagen van het systeem, het is alleen de vraag of het performance technisch haalbaar is.

Tja, entitybroker... Ik had al lang klant kunnen zijn. Helaas gooit Thomas zijn eigen glazen in door maar niet met een stabiele release te komen en in plaats daarvan bergen nieuwe features implementeert die misschien 1 klant van em nodig heeft. Zijn forumgedrag is hoogst amusant, maar marketingtechnisch is het niet zo slim

heh Ja ik snap die documentatie ook niet, 1 grote PDF met gaten. Maar het schijnt dat de entitybroker geen core business is, slechts een bijproduct. Zie je vaker overigens: consultancy firma's die hun mapper ook als product uitbrengen.

Bij een niet nader te noemen O/R mapper werden in een foreach objecten verwijderd uit de collectie waarover geloopt werd. Ach ja, als inserts en updates werken dan zal deleten ongetwijfeld ook goed gaan en hoeven we het niet te testen

Klinkt niet bijster solide, maar ik kan me herinneren dat ik ook dit soort foutjes wel gemaakt heb hoor. Testen van een O/R mapper is overigens wel bijna onbegonnen werk. Je mist altijd cases, van die situaties waarbij a EN b EN c en dan d+e en dan gaat het fout, je kunt testen tot je een ons weegt maar die mis je gewoon. Maar een basic CRUD operatie en dat het dan misgaat, tja, dat is wel erg ja .