Hej!

Jag har en fundering angående DataObjects.NET från www.x-tensive.com. Är det någon här som kan rekommendera den?

Case: Jag skriver v2 av ett system för ett företag. Jag har (i princip) designat tabellerna klara, tänkt igenom så att det inte ska bli flera "öppningar" samtidigt etc. Men... Jag hittade den där roliga saken av "misstag". Är den bra till något? Hur fungerar den rent praktiskt? Jag försöker leta info på deras hemsida, men det är svårt att veta om jag letar efter rätt saker eller inte. Vet som sagt i princip nada om deras produkt :/

Tack på förhand :)

/Mvh
Oskar Johansson

Wow ;) Det här är coola grejjer :)

Coola grejer som funnits i javavärlden de senaste fem åren :). Titta på projekt som Hibernate, TopLink (ägs nu av oracle), Cayenne, JDO (Java standard), Entity Beans (J2EE standard), Castor, OJB...för att bara nämna några. Av dessa projekt är Hibernate, Cayenne, Castor och OJB Open Source projekt, LGPL och BSD, så de kan utan bekymmer användas i komersiella projekt. Object/Relational mapping och peristensramverk är inget nytt men det rockar...jag håller med dig Onkel...det är coola grejer ;) Om du t ex använder Hibernate i ett projekt så kan du byta mellan ca 15 olika databaser som applikationen jobbar mot utan att du behöver ändra en enda kodrad i applikationen...det är väldigt bra när man har kunder på flera olika plattformar. I ett av de projekt jag arbetar med nu har vi, med Hibernate, kört tester för applikationen på SQL-Server, Oracle, MySQL och DB2 utan att ändra EN ENDA kodrad...det bara funkar..."right out of the box"...det är coolt :)

Men om jag inte är helt felinformerad kommer det väl ett O/R mappningsverktyg med asp2.net? Men vilka databaser kommer det att stödja?

/Nils

Tja, det är inte intressant att veta vad som kommer utan vad som fungerar just nu ;) Har lite tidspress på skiten nämligen... Och om jag satsar på det där så... :)

Jag (tror att jag) har lyckats övertyga de två andra om att köra på det här :)

Nils,

Problemet är att Ms välrd vs Java värld har skillt sig markant. MS värld har mer varit funktionsorienterat där prestanda vart i fokus, där man försökt skapa kvalité med hastighet. Men som många erfarat leder detta oftast till spagettikod, röriga program och minskad kvalité. Om man inte kör efter DNA och en viss objekt model. Nu har man "Äntligen" insett att Objekt Orienterade modellen rockar bäst. Dock är det för många MS utvecklare som sitter fast i Funktions tänket :-( men de kommer förhoppningsvis om många inte redan fått det ett mer Objekt Orienterat tänkande.

MS kör idag med Table model och inte ente så mycket efter Domain Model. Där de föredrar DataSets före O/R Mapping. Dock kommer det nu med Longhorn (och inte med .Net 2) något de kallar för Object Space som är just ett O/R Mapping ramverk. Detta kommer ligga med i Longhorn filsystems namespace (om jag inte minns helt fel. ) rätt dumt, men men...

Den är uppbyggd efter ett provider pattern där du lätt kan byta ut vilken datakälla du skall gå mot, Detta kan du även idag göra med ADO .Net 2 samt de Applikations Block MS tagit fram tillsammans med andra utvecklare. Problemet är mer att de inte byggt providers för alla Databaser du nämde. Men stödet finns för dem som vill nyttja det.

Då MS mest vill att man använder SQL Servern lägger de själva int ener så mycket energi med providers och engines för att gå mot andra databaskällor.

Det låter lite på dig att du vill berätta hur efter .Net världen är då saker redan i många år funnits i Javas värld. Det har du fullständigt rätt med. MS Utv språk var då Java blev stort inte inriktade på samma område de valde som jag tidigare sa den med funktionella orienteringen. Vilket då slog Java och gör även idag när det handlar om prestanda.
Läste en intervju med Anders H (C# skapare) om hans syn på O/R Mapping och han förespråkade den inte pga en rad olika skäl, så som cuncurrancy, hur objekten lever och aggerar etc... Även Java världen har lite delade åsikter ang detta. Skall en entitet bara finnas en gång? eller skall det skapas en ny varje gång man frågar efter samma data? Denna fråga kan ingen direkt svara på, dock är ju arkitektur mer en smaksak och leds av de krav ett system ställer så det finns ju inget rätt eller fel svar på just den frågan. Det är ren smaksak.

Mvh Johan

I mitt fall kan det nog passa ganska bra (tror jag?) Skrev ett litet test-program på 630 (!) rader varav kanske max 30 var db-kod. Enda problemet var väl hastigheten (som antagligen beror på att när jag körde hemifrån så var det väl inte världens bästa förbindelse, på servern gick dock bättre.)

"MS värld har mer varit funktionsorienterat där prestanda vart i fokus, där man försökt skapa kvalité med hastighet."

Haha...det där prestandasnacket håller inte. Titta på benchmarks där J2EE och .Net jämförs...i ett test är Java snabbast och i ett annat är MS snabbast...som man brukar säga..."lies, damned lies and benchmarks" :) Som t ex det benchmark test som theserverside gjorde som visade att ms var snabbast. Efter testet framkom det dock att det var ms som hade sponsrat hela testet och att applikationerna som byggts inte var jämförbara i arkitektur. theserverside gick sedan ut och sa att testet inte var tillförlitligt och de bad om ursäkt.

"Vilket då slog Java och gör även idag när det handlar om prestanda."

Heh...ännu mera bullshit...se svaret ovan.

"Läste en intervju med Anders H (C# skapare) om hans syn på O/R Mapping och han förespråkade den inte pga en rad olika skäl, så som cuncurrancy, hur objekten lever och aggerar etc... Även Java världen har lite delade åsikter ang detta."

Om man ska använda O/R mapping eller inte beror helt på vilka krav som ställs i ett projekt. Jag tycker att man är ganska trångsynt om man totalt dömer ut en teknik på det sätt som du säger att Anders H gör. Det finns både positiva och negativa egenskaper med O/R mapping, men det är som sagt kraven i ett projekt som bestämmer om det är en tillämpbar teknik eller inte. Jag vet inte om du säger att O/R mappning är bra eller dåligt eller om du bara håller med Anders H utan att ha någon egen erfarenhet?

"Skall en entitet bara finnas en gång? eller skall det skapas en ny varje gång man frågar efter samma data?"

Pratar vi cache strategier här eller?

/Nils

Nils,

Håller inte med Anders H till fullo, det är alltid kraven som ger svar på lösningen inte tvärt om.

Mvh Johan

"håller med Anders H utan att ha någon egen erfarenhet?"
Byggt en egen som jag använder fullt ut i alla mina projekt. Så ja jag har erfarenheter...

"Pratar vi cache strategier här eller?"
På sitt sätt. Pratar mer hur man kan se att objektet skulle leva i en verklig värld.
Många anser att hämtar men en person (John Doe) och frågar efter samma person igen så skall
inte en nya person skapas utan nyttja den som redan är skapad. Sedan finns de dem som ser person som data behållare och att dess verkliga ja finns i datan och tycker att det är helt ok att skapa ett nytt objekt med John DOe, för ändrar man en av dem ändras bådas data då man hämtar upp honom nästa gång. Jag kör på allternativ två i min O/R Mapping arkitektur detta för att jag inte haft tid att bygga stödet att själv välja hur man vill att entiteterna skall leva, hade tidsbrist då jag byggde den.

Mvh Johan

Så lägger jag mig i leken... ;)

De som hejjar på alt. 1 tycker också antagligen att det ska finnas datasets som fungerar perfekt som en enda instans på flera servrar ;)

Personligen tycker jag alt. 2 låter mer trovärdigt... Så fort man leker med databasen istället för primärminnet så blir det ju så...

Hej Nils!

Har du testat Hibernate-porten NHibernate än? (Den är i och för sig bara i alpha-läge just nu, men det vore kul att höra din åsikt eftersom du har jobbat med java-versionen.)

Mvh
Jimmy
www.jnsk.se/weblog/
###

"utan att du behöver ändra en enda kodrad i applikationen"

I teorin är det ju jättefint! Men ledsamt nog innebär 100% portabla applikationer problem i praktiken. De blir aldrig lika starka (ex. performance-mässigt) som applikationer som utnyttjar implementationsspecifika funktioner. Jämför exempelvis att använda SQL-satser direkt mot en databas mot att använda procedurer.

Hibernate är bra för vissa syften. Tror dock aldrig att det kommer att slå för transaktionsintensiva system. Objektorienterade databassystem är ju också jättefina men har aldrig slagit ordentligt.

/Kalle

Tja... Prestandan på burkarna blir ju bara högra hela tiden... Utvecklingstid vs. kostnad för några burkar extra vs. ändringar i mjukvaran vs. alla buggar vs. prestanda vs. kodens utseende etc. etc.

jag skulle nog satsa på att få ned utvecklingstid, buggar och få koden snygg. så fort man börjar peta på databaser så brukar de mest konstiga buggar dyka upp... om man då slipper tänka databaser utan mer oop så kan man slippa en del sådana.

det är klart, man kan få snabb kod som är 100% optimerad, men det kan bli jobbigt att få den klar fort samtidigt som den är lätt att ändra och inte ser ut som ett halv träsk.

Kalle...

Nu skall du få höra något av sanningens ord :-)
Java med full OO har typ aldrig varit direkt snabb, där har MS oftast legat på plats Nr 1 av de så kallade lätta språken. C++ tar jag inte ens med i diskusionen.

OO kräver mer anrop mer objekt m.m. vilket absolut slöar ner prestandan. Idag är .Net objekt orienterat och en god OO arkitektur medför en viss del prestanda problem. Men tack vare en effektiv CLR med cahcestöd med olika hanteringar m.m. blir .Net väldigt snabbt. (Går dock inte jämföra med C++ och andra språk.)

Att köra ramverk som Hibernate ger en viss overhead, det tar lite längre tid att utföra processer och ang transaktioner så är det inga som helst problem att ha fullt transaktionstöd med O/R Mapping verktyg. Och jag kan nog garantera att du missbrukar transaktioner redan idag där de egentligen inte behövs. En evigt tjat många gamla VB samt DNA kodare alltid skall bråka om.

Ang Objekt Orienterade databaser... Att det aldrig slått genom stort beror ju oftast på utbudet av Databashanterare. OO databas är ottroligt effektiv och vi kommer nog se mer sådana lösningar i framtiden då fler o fler patterns går mer o mer till ett sådant håll att vi snart troligen kommer behöva köra OO Databas. Idag nyttjar to m folk en Relatiosn Databas för att spara ner hela objekt som om det vore en OO Databas, detta i och med att man bl a vill öka O/R Verktygens prestanda.

Sedan den viktigaste biten som många inbitna DNA folk inte ännu riktigt förstått eller vill förstå är att prestnada är billigare att köpa än utvecklingstider. O/R Mapping sparar ottroligt många timmar och ökar både kvalité och kontroll över koden vilket gör att du har en mycket lägre kostnad än vad lite prestanda skulle ge. Nu är datorerna så snabba och billiga att du enkelt för några sparade arbetstimmar kan lätt skala ut eller upp för att få en applikation att rulla lika snabbt som om man la flera timmar på en hårdvara att gå så snabbt som möjligit.

Om vi tar system som kräver mycket data datatransaktioner i minuten eller sekunden, så är det ett krav, och kan man inte fixa kraven med ett O/R Mapping verktyg men kanske genom att köra så optimerad kod som möjligt.är ju det självklart ett måste. Dock har vi andra system som redan är klara för att hantera sådana transaktioner så som BizTalk, ICore proccess Server mfl...

Mvh Johan

Onkelborg...

:-) Kalas, skönt att höra att fler börjar tänka i de "Rätta" banorna.


Mvh Johan

;)

För övrigt: skulle inte ha något emot biztalk i det projekt jag leker med nu, men känns som att ekonomin inte riktigt tillåter det ;) skriver hellre ett eget då :)

(glömde tillägga att vi kör maxdb, inte mssql server, främst pga. priset)

Bra synpunkter, jag säger inte att det är något fel på Hibernate eller objektorientering, bara att de sista 10% prestanda i dagsläget inte kan uppnås med hibernate eller oo databaser eller 100% portabilitet.

/k

De där sista 10% kan man annars lägga på hårdvara så har man ett dubbelt så snabbt system :)

Jag tror inte att det tar längre tid att bygga systemet som är 10% snabbare men för en viss plattform, utan snarare tvärtom. Du gör en vinst både i utvecklingstid och prestanda om du från början väljer en plattform och sedan använder den specifika funktionalitet som finns där.

Däremot uppstår ju stora problem om man någon gång vill byta plattform.

Det är som vanligt, teori mot praktik.

Jag har haft diskussioner här med våra arkitekter respektive DBA'er. Arkitekterna rekommenderar att inte använda stored procedures av portabilitetsskäl. DBA'erna rekommenderar att använda stored procedures av prestanda och säkerhetsskäl.

/K

Som alltid, fördelar och nackdelar med allting ;)

Bara för att ta ett exempel: DataObjects.Net bör fungera så länge du kör .net, sedan klarar den både sqlserver, oracle samt maxdb utan problem (vill du byta mellan de där servrarna så är det bara själva datan i databasen som måste återskapas/loopas över, do skapar strukturen själv). dessutom är det ingen ms mjukvara så man kan räkna med att de kommer att försöka få den att fungera utanför ms (t.ex. mono, de har gjort lite försök men fått problem med implementationen av codedom i mono pga. lite buggar där osv.)

Det jag testat hittills med dataobjects (usch vad tjatig jag är) är att det fungerar bra. själva layouten på databasen i sig är inte sådär hemskt konstig, i princip rubbet borde gå att flytta över till t.ex. java, c++ etc. om man vill det.

Och den gången man vill byta platform så kan man ju fundera lite på varför ;) Någonting säger mig att det är svårt att bygga något stort, hyffsat snabbt och "snygg" kod utan att få problem med att saker inte fungerar på en annan platform oavsett hur man gör.

Johan, johan...att bli jämförd med Muhammed Ali är en ära, tack! Men tyvärr är jag inte, vad du än tror, i närheten av att vara så stor som han var. Men nu till dig Johan...jag förstår faktiskt inte överhuvudtaget varför du medverkar och skriver saker i ett forum. Om du inte klarar av att diskutera saker och ting utan att ironisera över personer (läs mig) så har du inget här att göra. Personangrepp hör inte hemma här. Ett arabiskt ordspråk säger: "Examine what is said, not him who speaks." Hoppas att jag slipper löjliga jämförelser med Ali i framtiden av dig Johan. Försök läsa det jag skriver, försök förstå det och diskutera det om du kan och vill...i alla andra fall ber jag dig att hålla dig borta från tangentbordet.

/Nils

Håller helt och hållet med Onkelborg i de här frågorna...att administrera, optimera och versionhantera en applikation som ska stödjas påt ex Oracle, SQL Server och DB2 kräver en hel del specialister och det kommer att bli tufft att underhålla och uppdatera en sådan applikation. Går man bara på en databas så är det enklare och då är kanske O/R Mapping inget alternativ.

Hinner inte skriva mycket mer nu om NHibernate osv, ska resa iväg ett par dagar men jag återkommer om jag kommer ihåg det :)

/Nils

Nils.

Skriver gärna och argumenterar kring saker, men kan inte du också hålla dig till ämnet och säga vad du tycker då? Att skriva alla Java tekniker som finns för O/R Mapping säger ju inte vad du anser om O/R Mapping i helhet mer än att det äår bra, men varför är det bra tycker du?

Mvh Johan

Och återigen nya antaganden om vem jag är och vad jag står för och återigen personangrepp...suck. Vill egentligen inte sjunka till din nivå Johan men jag vill försvara mig för dina påhopp.

"man kan ana att du vill visa folket hur stor o klok"

Det är du som "anar" det ja...jag tycker kanske inte alltid som du och så tolkar du det så...samtidigt skickar du ständigt själv ut länkar till din blog och pimpar för den...säger att du vill utbilda folket...dubbelmoral, ja, ja.

Om man inte klarar av en diskussion utan personangrepp ska man nog akta sig för att ge sig in i en diskussion överhuvudtaget...oavsett om det är irl eller på ett forum.

"Ärligt skiter jag i HA HA eller det har funnits länge putta dig kommentarer."

Några sådana har jag överhuvudtaget aldrig skrivit till dig...det är återigen du som tolkar mina inlägg så...kanske skulle du försöka minska din paranoia och sluta tro att folk förföljer dig eller bara vill jävlas med dig. Det här är faktiskt ett forum och då kan åsikterna gå isär...svårt att förstå det?

"Så att då prata om saker som redan funnits men inte i .Net världen anser jag inte onödigt eller oklokt som man kan tolka det när du är i farten."

Jag fattar faktiskt inte vad du menar här. Ska man inte kunna dra erfarenheter ifrån en plattform för att sedan kunna tillämpa dem på en annan?

"där du på nått sätt vill idiotförklara en. ok? Den stilen hör inte hit och det är det jag menar med citatet ovan."

Det där är återigen din tolkning av en vanlig diskussion...vakna upp och inse att folk faktiskt kan tycka olika!

Jag sätter härmed punkt för mig i denna tråd och i framtida diskussioner med Johan eftersom han liksom inte riktigt fattar eller vill fatta.

/Nils

Jag skrev:
"Läste en intervju med Anders H (C# skapare) om hans syn på O/R Mapping och han förespråkade den inte pga en rad olika skäl, så som cuncurrancy, hur objekten lever och aggerar etc... Även Java världen har lite delade åsikter ang detta."

Försökte hitta artikeln jag läste men fann inte den jag fick för mig att jag läst, kan ha blandat ihop det lite. Hittade i alla fall den jag syftade på. (tror jag)

Anders H säger att han inte föredrar tänkandet att allt är ett objekt, hämtar man en Customer så skall den läggas i Cache enligt många O/R Desing mönster. Detta synsätt tycker Anders H inte direkt är sant, han anser att hämtar man en Customer så skall det vara en kopia av databasen med senaste infon , så hämtar en annan en Customer hämtar han faktiskt en ny kopia av den data som finns i databasen. Sedan lägger han även fram lite argument ang prestanda etc. Han säger dock inte att O/R Mapping är kass men säger heller inte att han rekommenderar det utan tycker att den objekt tanke att hämta en är lite felaktigt.

Mvh Johan