Hej jag har läst Jimmy Nilsson's Applying Domain-Driven Design and Patterns som säkert flera här känner till, jag är ute lite efter det framework som han visar upp i boken NWorkSpace, vilket utifrån hans blogg han inte ger ut för att att den inte har den kvaliten som han vill för att ge ut den.

Men nu undrar jag om ni känner till något projekt som har den här grundfunktionaliteten?

Jag har kommit fram till att det projektet jag nu skall göra inte fungerar med NHibernate tyvärr eller några av dom liknande framework som finns idag, däremot är jag ute efter ett framework som ger mig interfacen, själva funktionaliteten med transaktioner, query byggar object osv.

Någon med lite tips?

NWorkspace var/är ju bara en wrapper som jimmy byggt över/runnt andra mappers.

Så vad jag vet så är de i princip bara en fasad för NHibernate
(vet inte om han har stöd för andra mappers på riktigt eller bara i teorin)

så om NWorkspace skulle lösa det du vill , så kan garanterat NHibernate göra det också.

Hmm, du kanske har rätt, skall ta och se mig om igen.

Jimmys ideer om NWorkspace var precis som roger säger ett försök att abstrahera bort infrastrukturen.

Dvs tanken var att du inte skulle jobba mot en specifik ORM utan mot ett generellt API som hade providers som implementerade mot olika ORM där NHibernate var en av dem.

Det är ingen ny ide, samma ideer finns i Java sedan innan och just nu tittar Jimmy på om inte LINQ kan vara den abstraktionsnivån över ORM som han letade efter.

Vad är det som gör att NH eller andra ORM inte funkar i ditt scenario?

Jag tyckte att NHibernate var lite för rörigt och vill inte blanda in det direkt i min applikation.

Men har tänkt över saken och om jag abstraherar bort det på rätt sätt så kan det nog komma att passa ändå.

Det jag var mest emot var att man inte kunde modifiera listorna som hibernate genererar, men om man löser det med någon typ av transportobject's så kommer det också att fungera har jag funderat ut..

Annars så letade jag efter något bra framework med färdigimplemmenterad funktionalitet i Repository, Collection, Factory, Entity basklasserna. Med ett bra designmönster hur dom borde hänga ihop.

Att sitta och läsa i litteratur och försöka få ihop något riktigt bra känns som att uppfinna hjulet så det var väl det jag var ute efter.

"Annars så letade jag efter något bra framework med färdigimplemmenterad funktionalitet i Repository, Collection, Factory, Entity basklasserna. Med ett bra designmönster hur dom borde hänga ihop."

Det här är precis det din domän måste bry sig om, att försöka hitta ett ramverk som abstraherar bort det här kommer att bli svårt utan du borde snarare leta efter verktyg som hjälper dig isf (vilket jag inte vet om det finns några).

"Det jag var mest emot var att man inte kunde modifiera listorna som hibernate genererar"
Det här förstod jag inte riktigt, hur menar du att det inte går att modifiera listorna?

Det med listorna menade jag följande.
Man måste ju definera att en lista med t.ex. Kunder skall defineras

IList<Customer> Customers
{
get { return this.customerList; }
set { this.customerList = value; }
}

Medans jag kanske vill ha en CustomerCollection som har metoder som GetByName(string customerName);, men har man ett CustomerTransportObject eller vad man skall kalla det som wrappas av Customer så kan man ju införa det jag vill.

Tråkigt att du inte känner till något bra det var precis det jag var ute efter, hade varit intressant att se hur andras applikationsarkitekturer med NHibernate ser ut.

Aha, jag förstår. Nej NH löser inte det problemet idag. Däremot gör NPersist det (www.puzzleframework.com) som använder en annan typ av modell.

Det låter mer som du är intresserad av exempel på implementationer än rena ramverk. Det tror jag blir väldigt svårt, om du inte kan hitta en open source produkt som är byggd enligt DDD så finns det nog bara skolboksexempel att tillgå, jag skall sparka lite på Jimmy och se om han känner till ngt.

Ja jag är ute efter mer sammansatta lösningar än små skolsexempel, jag vill se på hur skolexempel är ihopsatta till en större samling.

Satt och kollade in NHibernate igår lite mer vilket jag nog borde gjort innan jag ställde denna frågan.

Just nu har jag valt att ha transportobject som bara Domänlagret känner till, jag har också mina repositorys i detta lager för att domänentiteterna skall kunna ladda lazy. Jag funderar på att använda NHibernate som enbart en mapper och strunta i dess lazyload funktionalitet för att implemmentera egen, för att kunna ha typade Collections som jag beskrev en UserCollection för att kunna förenkla användadet i lagren ovan som t.e.x
WorkerCollection workerCollection = Company.Workers.GetByLastName("Pehrsson");

Eller tänker jag fel, vill minnas att jag läste i Jimmy's bok att man vill undvika typade collections, minns dock inte varför.

Upptäckte dock att om jag använder mig av transportobject som jag skickar in till mina entiteter så måste jag köra override på Equals() och GetHashCode() och bara vidarebefodra det till mitt transportobjekt. Är det många fler sådana saker man måste tänka på? Eller är detta med att använda transportobjekt bara något som gör min applikation onödigt komplex?

Har väl nu mer eller mindre kommit fram till att transportobjekt när det gäller NHibernate är onödigt.

Varför inte göra följande:

private IList<Customer> _customers; //Mappa och kör Lazy mot denna om så behövs..

public CustomerCollection Customers
{
get { return new CustomerCollection(this._customers)); } //Dependency Injection
}

Se til att din CustomerCollection konstruktor som tar IList<Customer> som argument, använder sig internet av denna list.. Då kan din CustomerCollection Lazy loadas och du kan ha ditt egna interface.

/Fredrik Normén [MVP]
blog: http://fredrik.nsquared2.com

Japp, precis så jag gjorde :).