Söker lite fördelar och nackdelar till att använda NHibernate istället för Linq To SQL / Linq To Entities.
Idag hittar jag lite nackdelar med att använda ex. Linq To SQL i och med att man oftast kastar in hela databasen (samtliga tabeller) i designern. Här ser jag själv nackdelen med Linq TO SQL i fall där man ex. Lägger till ett fält i en eller flera tabeller, så kommer detta innebär att man måste, eller i alla fall för min del, att man tagit bort hela tabellen i designern och kastat in den igen.
Fördelen med Nhibernate, som jag ser det i den jämförelsen är att man bara behöver lägga till en property i hbm-filen och i den klass som hbm-filen mappar mot. Vilken inte påverkar klassen i övrigt, säg om man har kustomiserat namnen på properties i klassen, tillskillnad mot fältnamnen i tabellen (Linq TO Sql).
En nackdel som jag ser med NHIbernate till skillnad från Linq TO Sql är att det tar lite längre tid att sätta upp ett grundläggande fungerade dal.
NHibernate har funnits ett tag och är mer moget, EF är fortfarande i sin linda tycker jag.
Jag tycker det känns som att EF klarar de enkla sakerna med GUI men när det blir lite mer komplexare och man inte kan använda GUI:t längre så blir det mycket jobbigare.
Fördelen med NHibernate är att du kan göra förändringar i allting som händer, vill du ladda dina Customer objekt på ett annat sätt eller skapa upp Customer objekten på ett speciellt sätt så kan du göra det.
Nackdelen är också att EF utgår från en datamodell istället för en domänmodell, den är inte heller persistence ignorent. Enda fördelen jag ser med EF idag är att du kan generera en ADO.NET Data Service (REST) för hela din application med CRUD. EF är den enda som stödjer IUpdatable of the shelf (Linq 2 SQL gör det ej). Annars tycker jag att EF Vote of no confidence fortfarande gäller (http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/) med tanke på de senaste besluten av EF-teamen gällandes state ochchange tracking info (EF bloggen samt http://weblogs.asp.net/aaguiar/archive/2007/03/30/ado-net-orcas-entity-framework-and-disconnected-operation.aspx). Linq 2 SQL fungerar utmärkt i vissa projekt, själv är jag Nhibernate-förespråkare, mycket pg. av 2:nd level cache och andra saker som inte finns i Linq 2 SQL, vad gäller EF blir det kanske bra år 2012 :) De ska ta in Jimmy Nilsson och Evans för samråd hur de ska kunna tillfredställa DDD-communityt
Nackdelen är också att EF utgår från en datamodell istället för en domänmodell, den är inte heller persistence ignorent. Enda fördelen jag ser med EF idag är att du kan generera en ADO.NET Data Service (REST) för hela din application med CRUD. EF är den enda som stödjer IUpdatable of the shelf (Linq 2 SQL gör det ej). Annars tycker jag att EF Vote of no confidence fortfarande gäller (http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/) med tanke på de senaste besluten av EF-teamen gällandes state ochchange tracking info (EF bloggen samt http://weblogs.asp.net/aaguiar/archive/2007/03/30/ado-net-orcas-entity-framework-and-disconnected-operation.aspx). Linq 2 SQL fungerar utmärkt i vissa projekt, själv är jag Nhibernate-förespråkare, mycket pg. av 2:nd level cache och andra saker som inte finns i Linq 2 SQL, vad gäller EF blir det kanske bra år 2012 :) De ska ta in Jimmy Nilsson och Evans för samråd hur de ska kunna tillfredställa DDD-communityt
Ja där ser man, Jimmy Nilsson och Evans. :)
Prövade på att använda NHibernate i ett exempel projekt, och ja, det diggar jag.
Tycker det är bra att man kan om man vill separera domänen helt och hållet från övrig kod, att man har mer kontroll över sina klasser och inte behöver lita sig på en designer (man vill ju som veta vad som händer under huven och på enkla sätt byta namn på fält etc utan att man skall behöva dra in datamodellen på nytt in i en designer) samt verkligen försäkra sig om att den är kärnan, om man nu skulle tänka sig i banorna Onion Architecture (http://jeffreypalermo.com/blog/the-onion-architecture-part-1/) Sen att man med NHibernate också på ett enklare sätt kan byta databas, utan att i någon större utsträckning behöva skriva om sina Repositoris eller för den delen Managers om man nu nyttjar den stilen. :)
Så det kan dröja innan EF är riktigt tillförlitligt.
Jag tror inte argumentet att man byter databas är speciellt ofta använt i realiteten, utan det handlar i mitt tycke snarare om en arkitektuellfråga, min domän ska inte veta något om hur den persitas för att prata svengelska :)
Designern har egentligen inget med EF att göra, vi kan hoppas på smarta verktyg för nhibernate i visual studio. Finns ju en del, men inga som fungerar speciellt bra i mitt tycke. Med med fluent nhibernate så slipper man mappningsfiler vilket är ett stort steg framåt :)
Problemet med Nhibernate är att det kräver mer av utvecklaren, men det är i mitt tycke ingen nackdel speciellt ofta :)
Jag tror inte argumentet att man byter databas är speciellt ofta använt i realiteten, utan det handlar i mitt tycke snarare om en arkitektuellfråga, min domän ska inte veta något om hur den persitas för att prata svengelska :)
Designern har egentligen inget med EF att göra, vi kan hoppas på smarta verktyg för nhibernate i visual studio. Finns ju en del, men inga som fungerar speciellt bra i mitt tycke. Med med fluent nhibernate så slipper man mappningsfiler vilket är ett stort steg framåt :)
Problemet med Nhibernate är att det kräver mer av utvecklaren, men det är i mitt tycke ingen nackdel speciellt ofta :)
Givetvis är inte argumentet att man byter databas speciellt ofta använt i realiteten. Tror jag! :)
Så vida inte systemet som bygger på NHibernate är en produkt som erbjuder olika databastyper som datakälla
Nackdelen är också att EF utgår från en datamodell istället för en domänmodell,
Nu var det längesedan jag använde EF, men det gäller bara vid generering. Du kan ju skriva dina mappningsfiler själv (även om jag aldrig lyckades klura ut hur man skulle, och det verkar onödigt komplext) och då kan du separerar din DomänModell från din DatabasModell. Det är väl till och med så att EF-teamet dragit det ett steg längre och lagt ytterligare ett skickt så du faktiskt har typ 2 mappnings filer som man måste hålla koll på!
Så typ så här: Domänmodell <-> EntityModell <-> Databasmodell
Nackdelen är också att EF utgår från en datamodell istället för en domänmodell,
Nu var det längesedan jag använde EF, men det gäller bara vid generering. Du kan ju skriva dina mappningsfiler själv (även om jag aldrig lyckades klura ut hur man skulle, och det verkar onödigt komplext) och då kan du separerar din DomänModell från din DatabasModell. Det är väl till och med så att EF-teamet dragit det ett steg längre och lagt ytterligare ett skickt så du faktiskt har typ 2 mappnings filer som man måste hålla koll på!
Så typ så här: Domänmodell <-> EntityModell <-> Databasmodell
- M
Jo, läste lite grann på MSDN om EF och mappningsfilerna... men jinks så krångligt det kändes.. fick inget häng på det, där av den vackra designern.
Där gillar jag NHIbernate mycket mer, mycket enklare och snabbare att skriva mappningsfilerna, dock däremot kanske lite jobbigare och skriva alla klasser också.
Där är väl det fina med LINQ TO SQL, de genereras och får passande namn direkt i stort sett. Kanske lite avsaknad funktionalitet, men duger gott i många fall. :)
Jag har precis börjat med EF och upplever att det inte är riktigt moget. Det tar i alla fall massa extra tid för mig att klura ut hur relativt enkla databasanrop skall göras. Men det kanske bara är jag :)
Om man t.ex. vill ha en sökning med olika många parametrar, sortera på en av kolumnerna och använda paging saknas det enligt mig en hel del. Jag har fått skriva säkert 150 rader kod för ca 10 parametrar och är inte klar än då "många till många" relationer ställer till det.
I ett annat projekt på mitt jobb används ActiveRecord från Castle Project (open source) vilket i grund och botten är NHibernate med lite bättre stöd för själva mappningen till databasen. Vad jag har hört är de rätt nöjda med det.
Jag tror EF kommer bli bra i sinom tid, men i dagsläget skulle inte jag rekommendera det...
281 ms totalt · 4 externa anrop · v20260731065814-full.1dc6f849
