Hej!

Jag står och undrar över hur utvecklingen går med .NET och andra liknande plattformar.

Hur separerar ni affärdslogik från persistens? Är det NHierbenate, Entity Framework (eller vad den heter), och separering med NSprings eller MEF (heter den så?).

Jag tycker det känns konstigt att det inte finns några objektorienterade databaser att använda, som integrerar bra ihop med .NET.

Förebilden jag har kollat på är GemStone/S, en helt objektorienterad databas, där man sparar objekt, inte rader och kolumner.

Jag tycker att det verkar vara så mycket kod man måste skriva för att hålla koll på objekt och lagring, och läsning.

Eller är jag helt enkelt för slö :-)

Daniel

Kan bara fylla på.

Är även jag intresserad av hur det går med objektorienterad datalagring.

Det som idag är dominerande är relationsdatabaser och har varit vanliga sedan 80 talet då de avlöste hierarkiska databaser.

Men objektorienterade databaser verker inte slagit igenom. Varför inte och då de även bättre borde passa ihop med objektorienterade programmering?

mvh Roland

Om du vill ha en OODB för .NET så finns det tex DB4O.
Den är GPL licensierad men finns även för kommerciellt bruk.

Om du vill persistera i en RDB så är NHibernate ett bra val.
Dock är det som du säger inte helt superintuitivt att komma igång med en riktig O/R mapper.
(Men när man väl fått kläm på det så är allt kalas)

Men om du vill ha något enklare för att bara komma igång så kan jag rekomendera Castle ActiveRecord.

Det är ett lager ovanpå NHibernate som exponerar ut 90-95% av NHibernates funktionallitet (enligt Ayende som är en av utvecklarna)

Castle AR är lite misförstått där många tror att man _måste_ ärva en basklass eller att man _måste_ ha save eller delete metoder direkt i entiteterna.
(Det är regler som gäller för AR som pattern, men Castle AR tillåter att man kringår det och kodar lite mer som mot en riktig mapper)

Så är inte fallet, du kan faktistk bygga rätt feta o rena modeller med Castle AR.


Jag tycker även att Linq To Sql har lite onödigt dåligt rykte.
Visst finns det problem o begränsningar med det, men det går att komma rätt långt med den också.

>>Varför inte och då de även bättre borde passa ihop med objektorienterade programmering?

För att de kopplar ihop ditt data med en specifik teknisk plattform.
t.ex. genom att lagra Java objekt eller .NET objekt.

Data lever längre än tekniska plattformar och du skulle då bli tvungen att migrera ut ditt data efter X tid.

De är dessutom bara effektiva för vissa uppgifter.
T.ex. att hämta delar av en objektgraf.

Medans de ofta är extremt bristande när det gäller aggregering av data.

Och eftersom alla ska trillsakas med att generera rapporter från sitt rådata så har det inte blivit något hit.

Hej Roger!

Jag tycker att det rent tekniskt borde vara bättre att lagra datan objektorienterat,
och även knyta business-logik så när datan som möjligt.

Jag förstår vad du menar med att det är svårt att få fram datan, men datan finns ju där. Dom ligger inte i tabeller, men det är ju inte så stor skillnad. Det är ju inte några större problem att representera en objektorienterad struktur i en relationsdatabas.

Du har också rätt att en objektorienterad databas är dålig på aggrigering, och är dess utom dålig på sökning och annat som en relationsdatabas är bättre på. Men om man har konstruerat strukturen på ett bra sätt borde man inte behöva så mycket sådant. Visst behöver man kunna söka, men då skapar man index. Det gör man ju i en relationsdatabas också.

Men det är klart. Jag ser många nackdelar med en objektorienterad databas. Exempelvis är skalning
inte speciellt lätt, om det inte finns stöd på låg nivå i databasen.

Men jag tror du har rätt, att man vågar inte binda sig så tätt knutet till en teknisk plattform när utvecklingen går så snabbt.
Samma problem har man ju med att skriva för mycket stored procedures. Många bygger hellre logiken i C# än i SQL även om det är lämpligare i SQL.

Daniel

Jag har själv ingen erfarenhet med objektorienterade databaser.
Varför måste de integreras så hårt med ett visst språk? Skulle det inte vara bättre om de har en viss struktur och det sedan finns "översättare" för de olika programmeringsspråken?

Ett objekt ser ju ungefär likadant ut oberoende av språk. (Åtminstone de språk jag programmerat i.)

>Skulle det inte vara bättre om de har en viss struktur och det sedan finns "översättare" för de olika
>programmeringsspråken?

Det är ju så det fungerar idag och "översättaren" är O/R mapper. En O/O mapper skulle antagligen vara enklare att konfigurerara men vinsten skulle inte vara så stor.

Det stora problemet är att det inte bara är programspråk som behöver komma åt data i databasen. Alla de verktyg man idag använder för att underhålla data i databasen skulle också behöva översättare. Detsamma gäller alla verktyg för att skapa rapporter.

Nu jobbar jag inte med såna applikationer själv men jag trodde inte att O/R mappning var något större problem. För prestanda använder man väl ändå produkter som memcached eller motsvarande.

Jo, jag tycker det. Jag tror inte problemt ligger där, utan att det helt enkelt inte finns några bra utbredda databaser. Om Microsoft skulle komma och säga att man nu kan lägga in Getters och Setters, så man
kan knyta en tabell till en klass, och enkelt kunna skiva objektorienterade stored procedures, i TSQL (TSQL++?) , eller .NET skulle nog folk få upp ögonen mer för datanära logik.

Man skulle självklart kunna bygga en kompilator som bygger TSQL-kod runt alla tabeller och med hjälp av tabellfunktioner, vyer och triggers få samma funktionalitet, men det blir nog rätt dålig prestanda.

Daniel

Grundläggande O/R mapping är inte speciellt avancerat. Men om man skall börja cacha, och se till att paralella trådar (användare) får uppdaterad information, och att man inte skriver över data måste man hålla koll på låsningar mm.

Om man bara kunde ha en "Begin transaction", andropa lite metoder på objekten för att göra ändringarna man vill, och sedan skriva "Commit", och i objekten _BARA_ behöva bry sig om affärslogik vore helt underbart.

Jag har inte kikat på NHirbenate och andra O/R mappers på länge, men sist jag kollade fick man hålla koll på en hel del själv. Jag kollade på Entity Framwork, och det var en hel del som jag inte var så värst imponerad över. Men det kommer mer i 2.0 (eller var det 4.0 den skulle heta).

Daniel