Håller på att utvärdera OR mapper som ska användas till ett nytt projekt där databasen innehåller > 100 tabeller. 1. I ett större projekt, ja det skall nog inte vara några problem använder det på ett ganska stort projekt på mitt jobb och det flyter på riktigt bra. Jag anser att det är en ganska stor community kring NHibernate samt att det och Java's alternativ Hibernate har funnits ett tag så att de flesta barnsjukdomar är borta iallfall. Tack för ditt svar. En sak till som oroar mig är den framtida utvecklingen av nHibernate. Då detta är en portning finns det kanske risk att Hibernate alltid prioriteras. Vad tror ni? NHibernate har en egen utvecklarcommunity som inte är beroende av Hibernates utvecklarcommunity. Det känns som ett viktigt val då vi startar ett lite större projekt som man ska utveckla och underahålla under en längre tid. Sen är det även för egen del som man vill nyttja en teknik som är hyffsat modern. Angående din fråga att man låser sig kring NHibernate, det behöver man inte alls göra, gör ett mellan lager så att dina andra lager inte känner av NHibernate alls, gör en egen Session som kapslar in NHibernate's session. Jo du har helt rätt. nHibernate funderingar
Har läst lite om nHibernate som verkar vara stor inom området men har en del funderingar som jag hoppas någon kan ge klarhet i.
-Vågar jag använda nHibernate i ett större projekt då det är Freeware, tänker på support, buggar osv?
-Mappningen sker i xml filer som görs manuellt. Är inte detta ett jätte jobb?
Sv: nHibernate funderingar
2. Mappning i XML tycker jag fungerar utmärkt, jag anser att det är nog mer jobb att sitta och skriva sqlsatser osv.Sv:nHibernate funderingar
Det lutar åt att vi kommer att köra nHibernate, ska bara känna lite på den först.
Hoppas att det inte är en allt för lång inkörningsperiod. Tur att det finns mycket dokumentation att tillgå.Sv: nHibernate funderingar
Sv:nHibernate funderingar
Sen undrar jag lite varför du oroar dig för den framtida utvecklingen. Om NHibernate löser dina problem idag, så lär den ju fortsätta lösa dina problem om ett par år? Bugfixar lär ju alltid droppa in så länge koden är öppen och nya features är ju inte ett måste för att fortsätta använda NH.Sv: nHibernate funderingar
Visst är det en risk man tar då man blir berorende av en tredje part, då känns det som att man bör tänka igenom det beslut en och kanske två gånnger.Sv:nHibernate funderingar
Jag gjorde så att jag skapade en egen session där jag la till den funktionalitet som var nödvändig från NHibernate's ISession, sedan delade jag ut en del av ISession's ansvar på Repositories och man kunde t.ex. ta min Session.Repositories.UserRepository.GetByXXX(...);
Självklart så hade den som standard getbyid, getall.Sv: nHibernate funderingar
Vi kommer nu att titta närmare på nHibernate och LLBLGenPro.
Den utav dessa två som passar våra behov får det bli.
Har skapat lista med måste och bör -ha.
Skall kunna hantera storedprocedures
Egna SQL satser skall kunna specificeras
Möjlighet att använda både i web, klient och service- applikationer
Ej tvunget att ärva från någon leverantörs specifik basklass
Tillgång till källkoden
Möjlighet att använda flera olika databaser
Använda likartad mappningssyntax som MS Linq
Stödja arvsfunktionalitet, ex. Fordon -> Personbil, Lastbil
Möjighet att styra "load" strategi, Lazy, Eager etc.
Tillgång till bra dokumentation
Stödja alla relationstyper.
Trevlig syntax, lätt att arbeta med.
kommer ni på mer, säg gärna till.