90 svar · 3 348 visningar · startad av thevice · sida 3 av 5
Hejsan, Jag gick över från ASP till .NET för nästan ett år sen, jag började att göra ett community så jag skulle lära mig grunderna i .NET då jag tycker att det är ett bra sätt att lära sig på. Communityt var från början bara något som jag skulle göra för att lära mig och sedan "skrota" det. Problemet ligger nu att det börjar bli seriöst. Sidan är gjord nu i MySQL och koden var något som jag trod
Läs frågan i sin helhet →Nickemannen skrev:
När ni pratar om DDD så måste jag rekommendera denna boken skriven av Jimmy Nilsson http://www.amazon.com/Applying-Domain-Driven-Design-Patterns-Examples/dp/0321268202
haha jag köpte den i torsdags kväll, den verkar ju helt suverän.
Jag såg att ni använder dataset/datatabeller för att fylla era objekt. Varför inte använda en datareader istället? Känns bättre och snabbare...
Sen såg jag att lite kod där man fyllde sina objekt i DAL. Jag skulle hellre vilja hålla DAL så rent som möjligt så att dessa går att använda till annat än bara till objekt. Jag tycker alltså att DAL bör returnera en datareader till BLL och i BLL så fyller man sina objekt. På detta sätt så blir inte DALS metoder så hårt knutna till objekten.
Här är ett bra enkelt exempel på DDD:
http://steve.emxsoftware.com/Domain+Driven+Design/DDD+Repositories++Factories
En annan sak som jag tycker man ska undvika är att ha alltför många inparameterar till en konstruktor. Som grov riktlinje kan man säga att "obligatoriska" värden bör sättas via konstruktorn, som tex id. Resten av värdena sätter du via tex en factory eller där du skapar ditt objekt. Jag skulle nog inte skicka in titel, text m.m. in i konstruktorn som i ett av kodexemplen.
Hinner inte skriva mer...dottern skriker och behöver uppmärksamhet :)
Lukaspojken skrev:
Jag såg att ni använder dataset/datatabeller för att fylla era objekt. Varför inte använda en datareader istället? Känns bättre och snabbare...
Sen såg jag att lite kod där man fyllde sina objekt i DAL. Jag skulle hellre vilja hålla DAL så rent som möjligt så att dessa går att använda till annat än bara till objekt. Jag tycker alltså att DAL bör returnera en datareader till BLL och i BLL så fyller man sina objekt. På detta sätt så blir inte DALS metoder så hårt knutna till objekten.
Här är ett bra enkelt exempel på DDD:
http://steve.emxsoftware.com/Domain+Driven+Design/DDD+Repositories++FactoriesEn annan sak som jag tycker man ska undvika är att ha alltför många inparameterar till en konstruktor. Som grov riktlinje kan man säga att "obligatoriska" värden bör sättas via konstruktorn, som tex id. Resten av värdena sätter du via tex en factory eller där du skapar ditt objekt. Jag skulle nog inte skicka in titel, text m.m. in i konstruktorn som i ett av kodexemplen.
Hinner inte skriva mer...dottern skriker och behöver uppmärksamhet :)
Det är nästa steg för mig. Jag har haft all logik i DAL för att det varit enklare att studera under tiden jag lär mig mer men har insett att DAL filerna blir alldeles för svåra att underhålla tom om man använder sig av regioner.
Tyvärr har jag inte riktigt greppat hur jag ska använda mig effektivt av dal/bll för att uppdatera. Som det är nu har jag skapat parametrarna i bll vilket är fel eftersom jag då måste skicka med allt till BLL och sedan anropa metoden för att spara. Ska jag som i Steve Eichert's exempel ett KundObject som sedan sparas med en metod i dal?
Nu utnyttjar jag inte mina entiteter (domänobjekt) till detta. Dessa används endast till att hämta värden, aldrig till att sätta värden. Har ju iofs inte kommit så långt i DDD förståelsen :)
Likasppojken skrev:
Jag såg att ni använder dataset/datatabeller för att fylla era objekt. Varför inte använda en datareader istället? Känns bättre och snabbare...
Jag använder mig av datatable av 2 anledningar.
1. Jag gillar inte att lämna över ansvaret att stänga min databaskoppling till ett annat lager än där jag öppnar den
2. Om jag hade använt en dataReader istället för en dataTable så måste jag ha en öppen koppling till databasen medans jag håller på och fyller mina objekt, och eftersom jag har möjligheten att lyssna på ett event onItemCreate så betyder det att jag har ingen som helst anning om hur långtid det tar att mappa datan från databasen till objekt. Och eftersom jag inte vill ha en koppling till databasen öppen längre än nödvändigt så känns det bättre för mig använda datatable istället för datareadern.
DataReadern är snabbare än DataTablen, men det kan betyda att din koppling till databasen är öppen en längre tid om du använder din dataReader när du mappar data från datareader till din objekt.
- M
-> Gladh
En annan anledning att använda dataset är när datasetet innehåller flera tabeller som har relation till varandra. I dessa fall klarar inte en datareader av att på ett smidigt sätt mappa ett komplext objekt. Så visst finns det fördelar med även det. Jag använder själv mig av det i vissa avseenden.
Punkt 1 är ganska intressant och viktig. Varför tror du att tex Steve Eichert's och andra inte följer denna punkt?
-> CatZ
Jag håller med om att man vill slippa mängder med inparametrar i DAL-metoder. För det känns inte riktigt rätt. Skulle man tex ha ett objekt som har hundra egenskaper så vill man ju inte ha en metod som har hundra inparametrar. Men samtidigt gillar jag inte att skicka ner ett visst objekt till en DAL-metod. Jag skulle kunna tänka mig två generella DAL-metoder: En för att updatera och en för att skapa en rad i databas. För att detta ska fungera så måste databasstrukturen i form av tabellnamn, kolumnnamn m.m. vara fast så att det räcker att skapa två generella metoder för update och insert. Dessa metoder tar emot object och använder sedan reflection för att skapa en paramatiserad sql-sats.
Om någon är intresserad av att testa att skriva två generella DAL-metoder för update och insert så är jag gärna med och hjälper till.
Gladh skrev:
Likasppojken skrev:
Jag såg att ni använder dataset/datatabeller för att fylla era objekt. Varför inte använda en datareader istället? Känns bättre och snabbare...
Jag använder mig av datatable av 2 anledningar.
1. Jag gillar inte att lämna över ansvaret att stänga min databaskoppling till ett annat lager än där jag öppnar den
2. Om jag hade använt en dataReader istället för en dataTable så måste jag ha en öppen koppling till databasen medans jag håller på och fyller mina objekt, och eftersom jag har möjligheten att lyssna på ett event onItemCreate så betyder det att jag har ingen som helst anning om hur långtid det tar att mappa datan från databasen till objekt. Och eftersom jag inte vill ha en koppling till databasen öppen längre än nödvändigt så känns det bättre för mig använda datatable istället för datareadern.DataReadern är snabbare än DataTablen, men det kan betyda att din koppling till databasen är öppen en längre tid om du använder din dataReader när du mappar data från datareader till din objekt.
- M
1. Det är en smaksak, men generellt sätt så är det en datareader som används iallfall de applikationer jag sett.
2. Tror inte det gör så mkt om databaskopplingen är öppen lite längre, är den det så får man designa så att databaskopplingen inte alls är öppen längre. Sedan får du ju dubell mappningstid om prestandan är mycket viktig så får du ju en större flaskhals när datan först måste mappas mot Datatable och sedan mot objekten
nickemannen skrev:
1. Det är en smaksak, men generellt sätt så är det en datareader som används iallfall de applikationer jag sett.
Det betyder inte att det är rätt, jag har sett riktigt dålig kod i många applikationer, men absolut inget som jag tänker ta efter ;)
nickemannen skrev:
Tror inte det gör så mkt om databaskopplingen är öppen lite längre,
Det är en av de mest grundläggande saker man lär sig om databasprogrammering och det är att se till att ha så lite kod som möjligt mellan öppnandet och stängandet av din databas.
nickemannen skrev:
är den det så får man designa så att databaskopplingen inte alls är öppen längre.
Hur skall du designa bort det? Det är något som måste lösas i ORMappern, eftersom det är där som där som den öppnas och stängs.
nickemannen skrev:
Sedan får du ju dubell mappningstid om prestandan är mycket viktig så får du ju en större flaskhals när datan först måste mappas mot Datatable och sedan mot objekten
När det gäller datatable istället för datareadern så är valet av datatable givetviss ett avbräck för prestandan (även om man knappast skulle märka det, även vid höglast), men skalbarheten ökar och man får bättre avskillningar mellan sina lager.
Vad många tycks glömma när man disskuterar hur länge en databaskoppling skall vara öppen, är att jag som utvecklar inte har en j-vla anning om när min kod kommer att exekveras, eftersom jag inte styr när min tråd skall få köras, det betyder att även om jag endast har en enda kodrad mellan öppnandet och stängandet av databasen så kan det tar en "bra stund" innan den raden är exekverad, eftersom "datorn" tycker att andra trådar är viktigare att exekverar än just den jag tycker är viktigast.
En annan sak som många verkar tycka är att den lila extra tid som databaskopplingen är öppen är inte så farligt, det är inte så många användare med mitt system, problemet är ju bara att de oftas är många applikationer som skall använda samma databas, och då blir det helt plötsligt väldigt intressant att se till så att man stänger ner antalet öppna kopplingar så snabbt som möjligt.
I vanliga hobbyprojekt där man sitter själv med en SQLdatabas och programmerar emot, så spelar det mindre roll, men om man börjar koppla upp sig mot en databas som redan är tungt belastat från en massa andra applikationer så kommer det märkas om du håller din databaskoppling öppen längre än nödvändigt, och när det märks så kostar det bra mycket mer än vad den "dubbla mappningen" kostar.
Prestanda och skalbarhet går aldrig hand i hand, ökar man det ena så minskas det andra, men det är f-n så mycket "billigare/lättare" att slänga till en server extra i slutändan, än att gå från extremt prestandakod till skalbar kod...
Men man utvecklar sin kod som man själv vill, eller ja, så som din arkitekt berättar för dig hur koden skall se ut...
- M
lukaspojken skrev:
En annan anledning att använda dataset är när datasetet innehåller flera tabeller som har relation till varandra. I dessa fall klarar inte en datareader av att på ett smidigt sätt mappa ett komplext objekt. Så visst finns det fördelar med även det. Jag använder själv mig av det i vissa avseenden.
Nu hänger jag inte riktig med. Fyller du först ett dataset med en massa olika datatables och sedan använder du detta dataset för att fylla ett komplext objekt? Om så varför gör du så, du kan ju lika gärna fylla olika delar i ditt objekt direkt från en datatable (eller datareader om du uppskattar det istället) och slippa gå omvägen via dataset och relationer. Du lär ju göra lika många anrop mot databasen i vilketfall som helst...
catz skrev:
Om någon är intresserad av att testa att skriva två generella DAL-metoder för update och insert så är jag gärna med och hjälper till.
Varsegod här har du dina 2 metoder, även om det egentligen bara är en :) http://www.webforum.nu/showthread.php?t=163666
Du kan inte utgå ifrån att du kan ha samma tabellnamn och samma kolumnnamn så att du kan skapa en generell metod för INSERT/UPDATE. Du måste ha någon sorts mappning mellan dina fält i ditt objekt och dina kolumner i databasen.
Du skulle kunna lösa det åp följande sätt, även om du skulle fått en FET spark i arslet om jag hade sett dig göra så här....
MY_GENERIC_COLUM
===========================
SPECIFIC_OBJECT_ID | OBJECT_FIELD_NAME | FIELDTYPE | BLOB_COLUMN
Här kan du nu spara ner vad som helst i denna kolumn, du berättar vilket ID objektet har, du berättar även vad objektes fältnamn heter som datan skall läsas till / skrevs ifrån. Du för ner information om vilken typ datan är som är sparad i din BLOB_COLUMN. Och till sist så har du din BLOB_COLUMN, här kan du nu spara ner allt från en bit till en en bild och du kan bygga något generellt för att skriva och hämta data från denna kolumn.
Men som sagt jag tror din DBA hade kastar ut dig ur hans rum, när du kommer med förslaget och din arkitekt hade slagit något hårt i huvudet på dig.... :)
- M
Gladh skrev:
nickemannen skrev:
1. Det är en smaksak, men generellt sätt så är det en datareader som används iallfall de applikationer jag sett.
Det betyder inte att det är rätt, jag har sett riktigt dålig kod i många applikationer, men absolut inget som jag tänker ta efter ;)
nickemannen skrev:
Tror inte det gör så mkt om databaskopplingen är öppen lite längre,
Det är en av de mest grundläggande saker man lär sig om databasprogrammering och det är att se till att ha så lite kod som möjligt mellan öppnandet och stängandet av din databas.
nickemannen skrev:
är den det så får man designa så att databaskopplingen inte alls är öppen längre.
Hur skall du designa bort det? Det är något som måste lösas i ORMappern, eftersom det är där som där som den öppnas och stängs.
nickemannen skrev:
Sedan får du ju dubell mappningstid om prestandan är mycket viktig så får du ju en större flaskhals när datan först måste mappas mot Datatable och sedan mot objekten
När det gäller datatable istället för datareadern så är valet av datatable givetviss ett avbräck för prestandan (även om man knappast skulle märka det, även vid höglast), men skalbarheten ökar och man får bättre avskillningar mellan sina lager.
Vad många tycks glömma när man disskuterar hur länge en databaskoppling skall vara öppen, är att jag som utvecklar inte har en j-vla anning om när min kod kommer att exekveras, eftersom jag inte styr när min tråd skall få köras, det betyder att även om jag endast har en enda kodrad mellan öppnandet och stängandet av databasen så kan det tar en "bra stund" innan den raden är exekverad, eftersom "datorn" tycker att andra trådar är viktigare att exekverar än just den jag tycker är viktigast.
En annan sak som många verkar tycka är att den lila extra tid som databaskopplingen är öppen är inte så farligt, det är inte så många användare med mitt system, problemet är ju bara att de oftas är många applikationer som skall använda samma databas, och då blir det helt plötsligt väldigt intressant att se till så att man stänger ner antalet öppna kopplingar så snabbt som möjligt.
I vanliga hobbyprojekt där man sitter själv med en SQLdatabas och programmerar emot, så spelar det mindre roll, men om man börjar koppla upp sig mot en databas som redan är tungt belastat från en massa andra applikationer så kommer det märkas om du håller din databaskoppling öppen längre än nödvändigt, och när det märks så kostar det bra mycket mer än vad den "dubbla mappningen" kostar.
Prestanda och skalbarhet går aldrig hand i hand, ökar man det ena så minskas det andra, men det är f-n så mycket "billigare/lättare" att slänga till en server extra i slutändan, än att gå från extremt prestandakod till skalbar kod...
Men man utvecklar sin kod som man själv vill, eller ja, så som din arkitekt berättar för dig hur koden skall se ut...
- M
Självklart menar jag designandet av OR/Mappern eller det lagret som använder sig av det. Som det nämdes tidigare med en Factory som tar emot DataReadern och som har per default ansvar att stänga datareadern och när datareadern stängs så stängs också anslutningen.
Det där du pratar om med en rad stämmer inte alls, bara för att du anropar Ramverket med en rad behöver inte det betyda att det anropet körs klart innan den kan byta tråd, utan det kan den göra även när du anropar ramverksspecifika metoder.
Dvs den kan lika gärna avbrytas när ramverket håller på och fyller Datatable som när du fyller objekten med en datareader.
Håller inte riktigt med när det gäller antalet rader kod mellan öppningar och stängningar utan mer tiden det tar att exekvera koden imellan, en kodrad kan ju ta längre tid en 3 t.ex. om man anropar ramverket.
Sedan om nu man använder sig av DataTable och inte DataReader så tycker jag det är dumt att mappa över den, lägg den hellre som datakälla i objektet..
Customer(DataRow dataRow);
Och använd er av dataRow:ens, reject, commit, save, delete, clone osv... :)..
Sedan det här med komplexiteten, använder man sig av ett lager för Dataåtkomst dvs ett lager som kommunicerar med databasen som sedan lämnar ifrån sig en reader som automatiskt stänger kopplingen när readern stängs och litar på lagret ovanför eftersom det följer ett designmönster som t.ex. Factory som det länkades till ovan så har du inte förhöjt komplexiteten något utan gjort i princip exakt samma sak bara det att det läggs till en rad i mappningsmetoden som stänger datareadern :).
Följer man det designmönstret så tror jag knappast att det blir några problem.
Men hur som helst så tycker jag att NHibernate passar de flesta fall eftersom här sköts allt detta åt dig, plus att man får en hel del andra möjligheter :).
Det handlar i mitt tycke om att man i stort sett aldrig vill ha den hårda kopplingen mellan lagrena, och det är inget man ska eftersträva.
Gladh skrev:
Nu hänger jag inte riktig med. Fyller du först ett dataset med en massa olika datatables och sedan använder du detta dataset för att fylla ett komplext objekt? Om så varför gör du så, du kan ju lika gärna fylla olika delar i ditt objekt direkt från en datatable (eller datareader om du uppskattar det istället) och slippa gå omvägen via dataset och relationer. Du lär ju göra lika många anrop mot databasen i vilketfall som helst...
Jag tror att Lukaspoken syftar på att man kan fylla ett dataset och alla dess tabeller med en enda Fill (mha TableMappings) och på så sätt enkelt få ut en struktur som man kan fylla på ifrån. Helt klart smidigt, men ändå inget jag någonsin vill göra. Dataseten blir bara en sak till att hålla reda på.
Nickemannen skrev:
Sedan om nu man använder sig av DataTable och inte DataReader så tycker jag det är dumt att mappa över den, lägg den hellre som datakälla i objektet..
Customer(DataRow dataRow);
Helst inte, för då har man knutit in DAL-implementeringen i Customer-klassen, men okej, jag kan köpa det i vissa lägen.
Beträffande DataTable vs DataReader så använder jag alltid den senare, men visst kan det finnas tillfällen då en DataTable kan passa bättre. Jag strävar dock efter att hålla objektinstantieringen så kortfattad som möjligt, så instantieringen av 1000 objekt blir antagligen effektivare och snällare mot Reader-uppkopplingen än instantieringen av 1000 DataRows i DataAdapter.Fill.
Nickemannen skrev:
Men hur som helst så tycker jag att NHibernate passar de flesta fall eftersom här sköts allt detta åt dig, plus att man får en hel del andra möjligheter :).
Håller med, NHibernate och dess kusiner har löst det flesta av de problem man kan få.
Jag är ändå inne lite på Gladhs spår. Gör man så behöver man egentligen bara skapa domänobjekten, mappern gör ju allt det andra. Ok för att det inte är 100% domän inriktat men hastigheten man utvecklar i med den lösningen blir ju... snabb! :)
Det som steve skrev på http://steve.emxsoftware.com/Domain...ries++Factories hjälpte mig att knyta ihop säcken lite bättre. Nu använder jag mig av mina domänobjekt för att spara också. Det blir väldigt mycket lättare för vem som helst att förstå koden på det viset.
Då tänker man Aha! Här sparar han ner alla värden till sitt Customer object och sedan anropar han Customer.Save(Customer).
Att använda datatable som object är ju också en tanke, jag har funderat på det men det föll inte riktigt i smaken. Ska ge det en tanke till..
nickemannen skrev:
Självklart menar jag designandet av OR/Mappern eller det lagret som använder sig av det. Som det nämdes tidigare med en Factory som tar emot DataReadern och som har per default ansvar att stänga datareadern och när datareadern stängs så stängs också anslutningen.
Återigen så är det så att det garanterat tar dig längre tid att mappa upp dina objekt via en datareader än vad det tar för .NET att fylla en datatable. Alltså kommer du ha en öppen koppling till databasen längre än nödvändigt, jag tycker det är ett "större" problem en den lilla prestandahit som det blir när man fylla dataTablen med data. Men det är ju min åsikt...
nickemannen skrev:
Det där du pratar om med en rad stämmer inte alls, bara för att du anropar Ramverket med en rad behöver inte det betyda att det anropet körs klart innan den kan byta tråd, utan det kan den göra även när du anropar ramverksspecifika metoder.
Dvs den kan lika gärna avbrytas när ramverket håller på och fyller Datatable som när du fyller objekten med en datareader.
Det var givetviss ett mycket förenklat exempel, och med en rad så menades mer en opertation, kallar man på en metod någon annanstans så är det givetviss så att det kommer utföras flera operationer vilka alla kan avbrytas när som helst.
nickemannen skrev:
Håller inte riktigt med när det gäller antalet rader kod mellan öppningar och stängningar utan mer tiden det tar att exekvera koden imellan, en kodrad kan ju ta längre tid en 3 t.ex. om man anropar ramverket.
Återigen så var en rad ett exempel, givetviss så tar det längre tid att anropa en metod som har 500 rader isig än att själv skriva 3 rader där man fyller en integer med värde. Men det har absolut inget med tid att göra, det det handlar om är att jag/du/vi som utvecklar inte kan påverkar (eller iallafall inte borde) vilka trådar som har prioritet att köras och ju fler operationer som händer mellan ett öppnande av databasen och den stängs destu större chans att OS:et går in och bryter din exekvering och låter andra trådar köra.
nickemannen skrev:
Sedan om nu man använder sig av DataTable och inte DataReader så tycker jag det är dumt att mappa över den, lägg den hellre som datakälla i objektet..
Customer(DataRow dataRow);
Det tycker jag inte är en bra lösning, för rätt vad det är så ändrar jag så att jag hämtar datan från en XML-fil istället för en databas och vad i hela världen skall jag då med en DataRow till. Nej mina entiter skall vara generella databärare som inte har en anning om var datan kommer ifrån...
nickemannen skrev:
Sedan det här med komplexiteten, använder man sig av ett lager för Dataåtkomst dvs ett lager som kommunicerar med databasen som sedan lämnar ifrån sig en reader som automatiskt stänger kopplingen när readern stängs och litar på lagret ovanför eftersom det följer ett designmönster som t.ex. Factory som det länkades till ovan så har du inte förhöjt komplexiteten något utan gjort i princip exakt samma sak bara det att det läggs till en rad i mappningsmetoden som stänger datareadern .
Så har jag inte löst mitt DAL, i mitt dal så har jag en metod som tar emot ett IDbCommand och returnerar tillbaka ett DataTable så jag kan med gott samvete använda mitt DAL till mer än bara min ORMapper, eftersom om mitt DAL öppnar databasen så kommer den stänga den också. Och det är just denna avskillning mellan de olika lagrerna som jag tycker är viktig, ms datareader är verkligen ett "brott" mot designmönster och lösningen med CommandBehavior är bara en nödlösning från MS för de klantat till sig med datareadern.
nickemannen skrev:
Men hur som helst så tycker jag att NHibernate passar de flesta fall eftersom här sköts allt detta åt dig, plus att man får en hel del andra möjligheter
Bra, ORMapper är vägen att gå... IMHO...
- M
CatZ skrev:
Att använda datatable som object är ju också en tanke, jag har funderat på det men det föll inte riktigt i smaken. Ska ge det en tanke till..
Tänk inte för mycket bara ;). Då är det till och med bättre med ett typat dataset istället. Med dataRown som "ett object" så har man liksom tappat idén med en OO, eftersom det inte är typsäkert, dessutom så kan du inte på enkla sätt utöka "ditt objekt" med valideringsregler och andra kodsnuttar, så fall är nickemannens förslag bättre att du håller en DataRow i minnet på objektet, och sedan använder du specifika properties på ditt objekt för att komma åt datan i datarrow:et.
Men jag tycker inte heller det är en bra lösning eftersom man kommer göra en massa castingar varje gång som man läser och skriver värden till datarown...
- M
Och att hålla en datatable i minnet måste ju vara mer prestandakrävande än en system.generics.list?
emisson skrev:
Jag strävar dock efter att hålla objektinstantieringen så kortfattad som möjligt, så instantieringen av 1000 objekt blir antagligen effektivare och snällare mot Reader-uppkopplingen än instantieringen av 1000 DataRows i DataAdapter.Fill.
Jag tror precis motsatsen, att fylla 1000 dataRows blir betydligt effektivare än att du skall mappa upp 1000 objekt med hjälp av reflections. Om du skriver mappningen själv unikt för varje class så kan jag hålla med dig att det antagligen går fortare att mappa upp de 1000 objekten, men om du bygger något generellt som måste använd reflections och mappningsdata så kommer det garanterat ta längre tid, och ju mer data som skall mappas upp destu mer kommer skillnaden att märkas...
Och då jag är rädd om min databaskoppling så vill jag stänga den så tidigt som möjligt.
- M
catz skrev:
Och att hålla en datatable i minnet måste ju vara mer prestandakrävande än en system.generics.list?
Kanske, men jag tror inte det är speciellt mycket som skiljer en datatable med sina datarows än en lista med objekt, det mesta som tar plats är ju datan och den är det samma. Sedan finns det säkert lite overhead i en datatable, men i det stora hela så märker du nog inget....
- M
Gladh skrev:
lukaspojken skrev:
En annan anledning att använda dataset är när datasetet innehåller flera tabeller som har relation till varandra. I dessa fall klarar inte en datareader av att på ett smidigt sätt mappa ett komplext objekt. Så visst finns det fördelar med även det. Jag använder själv mig av det i vissa avseenden.
Nu hänger jag inte riktig med. Fyller du först ett dataset med en massa olika datatables och sedan använder du detta dataset för att fylla ett komplext objekt? Om så varför gör du så, du kan ju lika gärna fylla olika delar i ditt objekt direkt från en datatable (eller datareader om du uppskattar det istället) och slippa gå omvägen via dataset och relationer. Du lär ju göra lika många anrop mot databasen i vilketfall som helst...
Så som vi gjorde i ett projekt var att skapa ett storeprocedurepaket med fem till sex procedurer. Detta paket hanterade all nödvändigt data som krävdes för att fylla ett visst komplext objekt. Paketet byggde vi så att man kunde hämta ett specifikt objekt, flera eller alla. Det blev riktigt smidigt att jobba med och när man skapade sitt dataset så gjorde man alltså bara ett enda anrop till databasen.
Ska kolla på er ORM-mapper som ni skapat. Jag tog en snabbtitt men jag måste nog ta och testa det innan jag kan säga något. Jag vet att det inte är rätt men det som jag gärna skulle vilja slippa på något smart sätt är att skapa en mappningsfil. Jag har inte jobbat med ORM-mappning men jag har läst en del och jag förstår principerna bakom det. Det som jag skulle kunna tänka mig att ha i en mappningsfil är undantagen, dvs då egenskapsnamnen skiljer sig från namnen i tabellkolumnen. Jag tycker att det känns onödigt att behöva mappa självklarheter som tex FirstName med Firstname.
Lukaspojken skrev:
Jag vet att det inte är rätt men det som jag gärna skulle vilja slippa på något smart sätt är att skapa en mappningsfil.
Många OR-mappers (t.ex. NHibernate) tillåter även att man definierar mappning mha av attribut på klasser och egenskaper. Du behöver inte använda någon mappningsfil.
lukaspojken skrev:
Jag tycker att det känns onödigt att behöva mappa självklarheter som tex FirstName med Firstname
Visst kan det kännas onödigt, men att bygga logiken för att välja mellan att använda mappningingen i visa fall och använda variablenamnet i andra fall, blir nog mer komplext och tidsödande än att bara hänvisa till mappningen, för du bör ju på något sätt informerar din ORMapper om fältet skall vara med i mappningen eller ej, du kan ju utgå ifrån att du alltid hämtar korrekt data från databasen och alla fält som är med i SQL satsen skall mappas mot objektet, men om du inte vill sitta och skriva SQL-satsen för hand själv, så måste du ju på något sätt berätta för ORMappern att just variablen FirstName skall vara med i SQL Satsen.
Så jag tror nog att det kommer mer kod för dig att hantera och komplixiteten ökar eftersom din mappning inte kommer vara speciellt intuativ att förstå.
Dessutom så måste man förstå en sak, att din domainObjekt, alltså objektet i din kod, egentligen inte bör återspeglas som en tabell i databasen, ditt domainobjekt är säkert mer komplext och uppbyggt med data från flera olika tabeller som har relationer till varandra...
lukaspojken skrev:
Paketet byggde vi så att man kunde hämta ett specifikt objekt, flera eller alla. Det blev riktigt smidigt att jobba med och när man skapade sitt dataset så gjorde man alltså bara ett enda anrop till databasen.
hmm.. det låter ju intressant, men hur fick ni tillbaka datan från databasen, för om den har delats upp som flera olika dataTables i ditt DataSet så måste det ju kommit tillbaka som flera olika "datablock", och det lilla jag sett av MS dataobjekt så kan man bara få tillbaka ett datablock åtgången och sedan får man göra ett nytt anrop för att få tillbaka nästa datablock. Så det hade varit intressant att kunna få tillbaka 2 "datablock" för att fylla dels mitt objekt och dels ett objekt inne i mitt objekt, men det har jag inte lyckas klura ut hur man gör med endast en SQL-sats...
- M