Bygga en egen dbklass

Och om du tittar närmare på det enorma klassbibliotek som genereras av din O/R mappern, vad hittar vi i dem?
jo, vanlig ADO.NET teknik förstås, såsom DataTables,DataRelation,DataRows,DataColumn,DataAdapters, SqlCommand.

Min O/R Mapper genererar inget av ovanstående (det är endast Bussiness classer som genereras/eller databas från klasserna). Däremot så används Givetviss ADO.NET för att hämta och skriva data till/från databasen.

Det som är relevant är hur mycket kod JAG behöver skriva. Och den inställningenborde varje programmerare ha. Annars kan vi lika gärna gå ner på assemblernivå och programmera, där har du prestanda.

Det är hyfsat orelevant om du måste skriva 2 eller 15 rader kod för att göra samma sak, visst det tar längre tid, men det som är relevant är hur välstruktrerad din kod är och hur enkel den är att underhålla och förändra. Om det sedan görs via VS.NET GUI eller skrivs förhand är upp till varje programmerare.

Och O/R mappern fyller också datatable:s likadant som en adapter fyller ett datatable i ett dataset.
Enda skillnaden mot ett dataset är att man med O/R mappern kan ta ur varje tabell för sig när man vill jobba med den.

Har du verkligen förstått vad en O/R Mapper är? En O/R Mapper fyller verkligen inte en datatable med data.

Jag tro du har missat hela poängen med vad man har en O/R Mapper till. Som jag skrev tidigare så är det helt okej att du vill använda DataSet och det är bra att du är nöjd med de och vad de kan.
Men återigen de är inget bra alternativ om man skall programmera ObjectOrienterat, och det spelar ingen roll om det är typsäkert eller ej, inte heller spelar det någon roll om du kan skapa dessa på 2 rader kod eller 50 rader kod, eftersom din lösning aldrig kommer att bli fullständigt objektorienterad med arv, interface och de fördelar som följer med OOP.

- M

Vad jag kan se är att Nöff och Gladh (och jag) pratar om olika saker.
Jag håller med dig Nöff att ditt sätt är både snabbt och smidigt. Men som Gladh säger, den lösningen passar sig inte för att bygga objekt-orienterade applikationer som du kan återanvända i andra projekt.
VS.NET är ett oerhört kraftfullt verktyg med många funktioner som underlättar skapandet av webbapplikationer. Men det jag och Gladh pratar om är att bygga objekt-orienterade lösningar som bara är att lyfta in i andra projekt.

Men vilken lösning man använder sig av beror på flera olika saker.
T.ex. hur stort är projektet, bygger jag ofta liknande projekt, osv.

...

En O/R Mapper fyller verkligen inte en datatable med data

Titta i de klassbibliotek som används för att Select:a objekt. Där lär du hitta det mesta.

Titta i de klassbibliotek som används för att Select:a objekt. Där lär du hitta det mesta.

Jag behöver inte titta i några klassbibliotek då jag har skrivit egna.

Så återigen en O/R Mapper fyller inte en datatable med data. Så här fungerar det enkelt.

Det finns 2 lager i en O/R Mapper ( man kan givetviss ha fler eller endast 1, men principiellt fungerar det som 2)

1. DataAccess Lager.
2. O/R Mapper lager.

När du gör en förfrågan efter en/flera objekt från databasen, så omvandlar ditt O/R Mapper lager denna förfrågan till en SQL fråga (antingen ren SQL, SQL med parameters eller ett CommandObjekt med parameters) som skickas till DataAccessLager. Detta lager hämtar sedan alla data från databasen med hjälp av; DataReader/DataTables/DataSets (varför man nu vill ha datasets).

Dessa objekt skickas sedan tillbaka till din O/R Mapper lager som omvandlar DataReader/DataTables/DataSets till en collection av objekt.

Så en O/R Mapper fyller inget datatable, den skapar och fyller objekt. Att sedan DAL:en använder sig av en dataTable är en annan sak, eftersom man lär använda de objekt som finns i ADO.NET. Du kan alltså inte få tag i ett DataTable från en O/R Mapper, du kan endast få tag i objekt/collection av objekt.

Valet står mellan att använda sig av ett DataTable eller en DataReader. En DataReader är snabbare men behåller en koppling till databasen längre, vilket försämrare skalbarheten.

Själv valde jag att returnera ett DataTable från mitt DAL då jag inte gillar den starka koppling mellan DAL och O/R Mappern som blir om man använder sig av DataReadern.

- M

Tänkte bara inflika med ett exempel där DataSet är väldigt bra.
Jag har några tillfällen där jag anropar en Stored Procedure som returnerar flera resultat. Med andra ord får jag 2 eller fler DataTables i en DataSet.

Gladhs O/R mapper lager skulle motsvara mitt Business Logic Layer som jag beskriver på http://pdc.se/blog/DisplayEntry.aspx?eid=5

Jag tror att det viktiga är att man ser till vad det är för lösning man ska bygga. Man vill självklart alltid att det ska gå så snabbt som möjligt men kraven man har kan vara olika från olika gång.

Det viktiga är att man har vetskap om vilka OLIKA sätt det finns att utföra saker och ting så att man kan använda den bästa lösningen till ett specifikt projekt.

Tycker att Nöff och Gladh har hamnat i klinch och kommer förmodligen aldrig att vara överens. Men jag hoppas att de börjar förstå att båda lösningarna fungerar men båda kanske inte passar alla.
Allt beror på vad man själv är ute efter.

Tycker att Nöff och Gladh har hamnat i klinch och kommer förmodligen aldrig att vara överens. Men jag hoppas att de börjar förstå att båda lösningarna fungerar men båda kanske inte passar alla.

Inte om DataSet inte, jag ser endast ett användings område för dessa klumpiga monster :)

Jag använder min O/R Mapper så fort jag har med OO att göra, skall jag bara presentera data så är DataReader vägen att gå. Skulle jag dock vilja återskapa de funktionallitet som finns i typ access (som Nöff föreslog) så skulle jag använda mig av dem. Jag har dock aldrig stött på den uppgiften än.

Men det är fritt för var och en att välja, bara det att mitt sätt är rätt :)

- M

Hur ser tanken ut bakom en O/R Mapper?
Säg att jag vill hantera ett användar/personuppgifter-register ifrån en databas. På vilket sätt kan jag vinna genom att använda en O/R mapper gentemot att skapa en klass med en massa funktioner för varje hantering?

ex. på hur jag har nu
personhantering.addUser(namn, epost, osv)
personhantering.remUser(id)

Fördelen blir att du endast behöver en method för INSERT, en för UPDATE, en för SELECT och en för DELETE för alla dina objekt.

Så istället för att göra:

user.Save();
article.Save();
customer.Save();

Så har du en method som kan spara vilket av dina objekt som helst.

ORMapper.Save(user);
ORMapper.Save(article);
OPMapper.Save(customer);

Din ORMapper "omvandlar" sedan ditt objekt till en SQL sträng som skickas till ditt DAL och så är ditt objekt sparat.

Detta gör att om du skriver/införskaffar ett bra O/R Mapper så kan den hantera all din databas kommunikation och du slipper skriva din .Save() .Update() .Delete() .Select() methoder för alla dina klasser. Med andra ord så spara du massor med tid och dessutom får du en OO struktur i din kod.

Givetivss så tappar du i prestanda jämfört med om du skriver specifikat funktioner för varje klass. Denna förlust är dock uppvägd flera gånger om av den underhållningseffekt du får, lika enkelt blir det att bygga ut din OR Mapper med fler funktioner.

Säg att du vill plocka ut en delmängd av dina objekt från en collection. Med en O/R Mapper så skapar man ett collection objekt som vajre collectionType får ärva ifrån, detta objekt har sedan en method som heter typ: GetRange(start, end).

Om du då vill hämta ut typ 10 kunder från dina 100 som du har i en collection klass.

CustomerCollection customers = (CustomerCollection) ORMapper.GetCollection(typeOf(Customer));
customers.GetRange(10,20);

Först så hämtar du ut alla kunder från din databas till en collection, sedan hämtar du ut kunderna 10 till 20 från denna collection.

Om du har en klass med massa funktioner för varje hantering, så måste du skapa en method för varje typ som du vill hämta en delmängd för. Om du har Kunder och Articlar, så blir det 2 funktioner osv osv...

Sedan är det enkelt att bygga ut med typ, en slumptals uttagning. Ta ut en slumpvald kund ur collection.

CustomerCollection customers = (CustomerCollection) ORMapper.GetCollection(typeOf(Customer));
customers.GetRandom();

Eller om du vill sortera på någon property i din klass.

CustomerCollection customers = (CustomerCollection) ORMapper.GetCollection(typeOf(Customer));
customers.GetSorted("Name", "Ascending");

Nu får du alla dina kunder sorterade efter namn i stigande ordning.

med mera, med mera

- magnus

En av de största fördelarna jag märker av när jag använder en o/r mapper är att koden är så bra uppdelad i lager.

Jag kan utan problem samarbeta med en designer eller webbprogrammerare som bara använder o/r mapperns metoder för att få rätt objekt att hämta/lämna sin information :)

Jag kan även som tidigare sagt lyfta in den i andra projekt och slippa generera om eller i värsta fall koda om logik för hand.

Hur ser tanken ut bakom en O/R Mapper?
Säg att jag vill hantera ett användar/personuppgifter-register ifrån en databas. På vilket sätt kan jag vinna genom att använda en O/R mapper gentemot att skapa en klass med en massa funktioner för varje hantering?

Men den o/r mapper jag använder skulle du göra så här:

UserClass u = TheObjectMaster.GetBroker().RetrieveObjects(typeof(UserClass),RetrieveType.DETAILED);

Vill jag bara hämta objekt med ett visst kriterium gör jag så här:

CCriteria c = new CCriteria();
c.AddComparition(new CComparition("UserName","Arne",ComparitionType.LIKE));

UserClass u = TheObjectMaster.GetBroker().RetrieveObjects(typeof(UserClass), c, RetrieveType.DETAILED);

Det som behövs för att det skall fungera är naturligtvis en UserClass. Den måste vara uppmärkt med lite attribut så den vet varifrån datat skall hämtas men är en liten mängd information och dessutom kan jag automatgenerera den om jag vill.

Detta fungerar oberoenda av vilken databas man använder sig av!

Verkar intressant med O/R mappers, har aldrig använt mig av det utan byggde ett eget litet system med BL/BDL/DL, känns dock som om det inte är så pass OO som jag vill ha det samt att det blir mera onödigt kodande än vad som är nödvändigt.

Skulle vara intressant att se koden bakom ett sånt här system. Ingen som har någon länk eller har lust att visa lite mer? Det jag hittat på nätet verkar också enbart "finnas" för MSsql...

Så återigen en O/R Mapper fyller inte en datatable med data. Så här fungerar det enkelt.

Från databasen hämtar O/R mappern en tabell till ett DataTable och från det DataTable:t skapar den det objekt som representerar databastabellen.
Kalla det collections du. Men vad som är väldigt underligt är att du själv är medveten om att O/R mappern fyller
ett ADO.NET DataTable men ändå förnekar du det.

Fördelen blir att du endast behöver en method för INSERT, en för UPDATE, en för SELECT och en för DELETE för alla dina objekt.

Det där känns föråldrat.
Har du kanske undgått att i det dataset jag presenterade för er tidigare behövs ingedera, eftersom det är ett Händelsestyrt DataSet. Varför använda någon metod alls för att anropa databasen när dataset:et kan "känna" av om något förändrats och INSERT/UPDATE/DELETE tabellerna i databasen automatiskt efter det. Och detta gäller ALLA tabeller i hela databasen. dataset:et representerar hela databasens tabeller och inte enstaka tabeller.
Och denna datasetklass återanvänder man sedan i alla andra projekt man har, den behöver aldrig förändras eller uppdateras.

Och DataSet är inte långsammare än O/R mapper.
Visst ett "original typat dataset" är det pga den innehåller alla DataTable:s. O/R mappern funkar så att den tar ur varje databastabell för sig. Men om man sätter public på de typade
DataTables:arna i DataSet:et så kan man också ta ur varje DataTable för sig som jag beskrev ovan. Och då ser det ut enligt nedan om man jämför med en O/R mapper:

O/R mapper:
Databastabell-->DataTable-->Collection <---------objektet som representerar databastabellen

Mitt "public" DataSet:
Databastabell-->DataTable <---------objektet som representerar databastabellen

Som ni ser är det en omöjlighet att det dataset jag nyss gjorde skulle vara långsammare än en O/R mapper.

CustomerCollection customers = (CustomerCollection) ORMapper.GetCollection(typeOf(Customer));
customers.GetRange(10,20);

Har dataset gjort sedan tidernas begynnelse (fast på ett enklare sätt)
DataRow[] customererows=dataSet11.customers.Select("ID<20 AND ID>10");

Jag kan utan problem samarbeta med en designer eller webbprogrammerare som bara använder o/r mapperns metoder för att få rätt objekt att hämta/lämna sin information

Det är exakt så ett dataset funkar.
Det var då t******* att ni inte förstår vad ett dataset egentligen är för nåt.
Jag har försökt förklara på alla tänkbara sätt, men ..... det går inte fram.. hahahahaa :)

Tänkte bara inflika med ett exempel där DataSet är väldigt bra.
Jag har några tillfällen där jag anropar en Stored Procedure som returnerar flera resultat. Med andra ord får jag 2 eller fler DataTables i en DataSet.

Fint. Fortsätt utforska datasets :birp

Från databasen hämtar O/R mappern en tabell till ett DataTable och från det DataTable:t skapar den det objekt som representerar databastabellen.
Kalla det collections du. Men vad som är väldigt underligt är att du själv är medveten om att O/R mappern fyller
ett ADO.NET DataTable men ändå förnekar du det.

Nöff är du inte läskunnig. Min O/R Mapper fyller inget DataTable det gör mitt DAL. Vilket i princip är helt jävla ointressant eftersom du aldrig kan komma åt denna DataTable via O/R Mappern, så NEJ en O/R Mapper fyller inte en DataTable med data, den använder en DataTable (om man vill) för att fylla objekten eller collections av objekt. Det är en j-vla skillnad.

Har dataset gjort sedan tidernas begynnelse (fast på ett enklare sätt)
DataRow[] customererows=dataSet11.customers.Select("ID<20 AND ID>10");

Återigen så undrar jag över din läsförmåga. Detta var exempel på varför man skall använda en O/R Mapper istället för att skriva olika DataManager klasser för alla sina objekt. Och har inget med dataset att göra, dessa var inte ens nämda i hela inlägget.
Jag ser dock inte varför det skulle vara enklare att skriva:

DataRow[] customererows=dataSet11.customers.Select("ID<20 AND ID>10");

Jämfört med:

CusomerCollection customersRange = customers.GetRange(10,20);

Jag skriver ju till och med mindre kod än vad du gör, hur kan det då vara svårare.

Och DataSet är inte långsammare än O/R mapper.

Jämför lite äppel med päron här kanske. Du kan inte jämför prestandan för ett DataSet med en O/R Mapper eftersom de inte gör samma sak. Återigen betvilvar jag på att du vet vad en O/R Mapper är.

O/R Mappern fyller objekt, sedan så använder man dessa objekt när man vill ha tag i datan (alltså ärO/R Mappern endast inblanda när man gör access mot databasen). Alltså så får man jämför hur långtid det tar att fylla ett DataSet med data och hur långtid det tar att fylla objekt med data med hjälp av en O/R Mapper. Här är det mycket möjligt att DataSeten är lite snabbare, har faktiskt inte kontrollerat detta, men antar att skillnaden i tid är minimal mellan de båda.

Sedan när man vill ha tag i data för objekten så anropar jag objektet direkt, medans du måste gå omvägen via DataSetet, vilket gör att det är snabbare att få fram data via objekten.

Inser att det är meningslös att diskutera med dig då du inte har förstått de grundläggande med en O/R Mapper. Hur den fungerar, vad man har den till och inte heller fördelen med den.

Du får gärna använda dina DataSets/Typa DataSets hur mycket du vill, det bryr jag mig inte om, och är glad att du har hittat något som passar dig.

Men att klanka ner på något som du inte har en anning om vad det är eller hur det fungerar är rätt korkat.

- M

så NEJ en O/R Mapper fyller inte en DataTable med data,

CustomerCollection customers = (CustomerCollection) ORMapper.GetCollection(typeOf(Customer));
customers.GetRange(10,20);

Denna raden tex. vad försigår under ytan??. Förstår du inte att den först använder en vanlig ADO.NET adapter för att fylla ett ADO.NET DataTable med data från databasen, och sen använder den detta DataTable för att fylla en collection med datan, DEN FYLLER ETT DATATABLE PRECIS SOM ETT DATASET GÖR, skillnaden är att DataSet:et stannar där, punkt!. Medans O/R mappern går vidare och fyller en Collection av DataTable:t, vilket gör O/R mappern jävligt mycket långsammare än DataSet. Jag struntar i om det är ditt DAL som gör det, hör inte dit. Saken är den att DEN GÖR DET, den fyller ett DataTable, det är så det fungerar, det är det som varit frågan hela tiden.

Sedan när man vill ha tag i data för objekten så anropar jag objektet direkt, medans du måste gå omvägen via DataSetet, vilket gör att det är snabbare att få fram data via objekten.

Hallo, jag visade dig precis hur man får "direct access" till de typade DataTable. Begrep du nåt av det? nej, det var väl kanske för mycket begärt. De typade DataTable:s i min datasetklass kan arbeta helt fristående från dataset:et, och jag kan lägga dem i egna klasser om jag vill. Och iom att man stannar vid DataTable:t så får man bättre prestanda än O/R mapper. :P

Nä, nu får ni två ta och ge er.

Ni pratar om två helt olika saker och ni jobbar på två helt olika sätt.

Nöff, du får läsa på vad en O/R mapper gör för det är inte den som fyller en DataTable det är en klass under den, Data Access Layer. O/R mappern är Business Logic som tar den returnerade DataTables från DAL och översätter den till ett starkt typat Business Object som den returnerar. O/R mappern.

Nu börjar ni släng ur er personliga påhopp. Man måste veta när det är dags att sluta diskutera och om ni två vill fortsätta så tycker jag att ni kan göra det privat.

Ni arbetar på två helt olika sätt. Nöff använder Visual Studios inbyggda funktioner för att snabbt bygga sina webblösningar.
Gladh använder Objekt-orienterad teknik för att kunna återanvända en lösning i flera projekt. Han använder O/R mappern för att snabbt skapa sin affärslogik.

Sluta tjafsa nu eller lyssna på vad den andre säger.
Vad sjutton hände med moderatorer?

...

O/R mappern är Business Logic som tar den returnerade DataTables från DAL och översätter den till ett starkt typat Business Object som den returnerar. O/R mappern

Men det hör ju inte så mycket till saken, ett DataTable måste fyllas, och det gör den på exakt samma sätt som DataTable:t i dataset:et blir fyllt, med en adapter. För att körningstrukturen ser ut såhär om man jämför:

O/R mapper:
Databastabell-->DataTable-->Collection <---------objektet som representerar databastabellen.

Mitt "public" DataSet:
Databastabell-->Typat DataTable <---------objektet som representerar databastabellen.

Det är en väldig overhead eftersom den måste fylla 2 objekt istället för 1 objekt om man jämför med mitt dataset-DataTable

Jaaaa, men Gladh har aldrig sagt att det inte fylls någon DataTable, han har sagt att O/R mappern INTE fyller någon DataTable.

Du kan prata om overhead och du kan fortsätta jobba på ditt sätt för det verkar passa dig.
Gladh kommer fortsätta jobba på sitt sätt med N-tier och O/R mapper som underlättar hans arbete.
Jag kommer fortsätta jobba på mitt sätt med N-tier men utan O/R-mapper. Hur jag gör går att läsa i min blog
Jag skulle inte kunna använda någon av era metoder för de passar inte i min arbetsmetodik och jag har provat båda.
Men jag säger inte aldrig för det kan dyka upp projekt med engångslösningar där någon av dem passar bra.

Ni har olika arbetsmetodik och ärligt talat så är din jämförelse med två objekt mot ett av dina fel. Gör ett korrekt benchmark test innan du kommer med sådana saker. Det handlar om förkompilerade klasser i flerskikt mot datasetsklasser som VS.NET skapar.
Jag har ingen aning om hur prestandan mellan dessa två skiljer sig och jag tänker inte gissa.

En sak är i alla fall säker. En bra programmerare lyssnar på vad andra säger och utvärderar om arbetssättet snabbar upp ens egens metodik. Och en utvärdering består inte i vad man tror utan baseras på fakta. Kan även tillägga att det finns en anledning till att Microsoft inkluderar en O/R mapper med Whidbey.

Intressant diskussion :)

Känns dock som som Pdahlen säger att ämnet rann ut lite i sanden på slutet. Funderar på att "uppgradera" min nuvarande struktur , har insett att den inte är så bra ändå så har några frågor.

O/R mappern verkar ju vara ett bra system men säg att vi ska skippa hela delen med SP, använder inte MSSql och har i ärlighetens namn inte insett vad som nu är så bra med dem, bättre säkerhet och hastighet men känns som mera arbete än vad det ger.

Det system jag har idag ser ut ngt i denna stilen:

Databas = mysql

DAL = Ansluter till DL och innehåller funktioner för att returnera reader/datatable etc

DL = Hämtar data

BDL = Bearbetar datan

BL = Bearbetar innan presentation

PL = presentation

Blev väl lite rörigt kanske.

O/R mappern "byter" alltså ut DL och BDL ovan och skickar ner objekt till BL? Försvinner då allt SQL-kodande, det borde det ju göra eller? Använder ju inte SP.

Någon som vet om den O/R mapper i Whidbey har stöd för mysql?

Det handlar om förkompilerade klasser i flerskikt mot datasetsklasser som VS.NET skapar.

Vill inte upprepa mig och så. Men jag gjorde ju en .DLL fil av mitt dataset på sid nr 2, och det går jättebra att göra .DLL filer av de typade DataTables som finns inne i det typade DataSet:et också, DataTables fungerar jättebra utan DataSet. Men jag gillar att ha allt på samma ställe. Men det är som sagt upp till en själv.

Medans O/R mappern går vidare och fyller en Collection av DataTable:t

Jag kan inte förstå vad det är som är så svårt att förstå att min O/R Mapper inte fyller en DataTable. Och absoult inte en collection av DataTables.

Precis som Patrik säger så får O/R Mappern en DataTable att jobba med, precis som DataSetet får en DataTable att jobba med från DAL:et (DataSetet kan få flera, min O/R Mapper får ENDAST 1, aldrig någon collection).
Jag har aldrig någonsin påstått att det inte skall blandas in DataTables/DataReaders för att O/R Mappern skall fungera. Självklart så måste O/R Mappern få sin data från databasen på något sätt och givetviss använder man de klasser som finns att tillgå i ADO.NET, det säger sig själv, och jag har påpekat det i flera inlägg ovan.

Men återigen O/R Mappern fyller inte ett DataTable, lika lite som DataSetet fyller en DataTable (det är DataAdaptern som fyller ett DataTable och då används en DataReader). Båda två använder de DataTables som levereras från DAL:et. Du blandar ihop funktionerna för de olika lagren.

O/R mapper:
Databastabell-->DataTable-->Collection <---------objektet som representerar databastabellen.

Mitt "public" DataSet:
Databastabell-->Typat DataTable <---------objektet som representerar databastabellen.

Det är en väldig overhead eftersom den måste fylla 2 objekt istället för 1 objekt om man jämför med mitt dataset-DataTable

MUHUHUUHUH

Och kostnaden att gå från ett DataSet till ett Typat DataSet är noll och ingen. Skärp dig!!!

Antingen har du kostnaden i prestanda när du skapar ditt Typade DataSet (det är rätt friskt med TypeCastning här, samt användning av ditt XML-schema som är skapat, och XML-hantering är INTE snabb i .NET), eller så har du kostnaden när du skall hämta ut data från ett vanligt DataSet (eftersom det måste typecastas här istället, alla dina värden är ju sparade som object, och måste kastas till rätt typ.)

Denna kostnad kan motsvaras med vad det tar att skapa ett objekt och fylla detta med data från DataTable (jag slipper ju skapa en dataset och låten detta leka runt med sina XML-Scheman)

Skillnaden i prestanda för att ladda ett TypatDataSet eller en Collection av data är minimal åt något av hållen.

Det är en väldig overhead eftersom den måste fylla 2 objekt istället för 1 objekt om man jämför med mitt dataset-DataTable

Jag hade varit riktigt glad om min O/R Mapper endast hade behövt fylla 2 objekt för att få ut data från en databastabell.

Du verkar tro att ingetting görs under ytan, bara för att det inte syns i din kod vad som händer så betyder inte det att det inte kostar i prestanda.

- M

eller så har du kostnaden när du skall hämta ut data från ett vanligt DataSet (eftersom det måste typecastas här istället, alla dina värden är ju sparade som object, och måste kastas till rätt typ

Din Collection är också starkt typat, så du kastar stenar i glashus än en gång. Så det där höll inte.

min O/R Mapper inte fyller en DataTable. Och absoult inte en collection av DataTables

Har jag skrivit att den tillverkar en collection av DataTables?, var har du fått det ifrån. Den skapar en egen Collection av DataTable:t har du svårt för att läsa?.

Antingen har du kostnaden i prestanda när du skapar ditt Typade DataSet (det är rätt friskt med TypeCastning här, samt användning av ditt XML-schema som är skapat, och XML-hantering är INTE snabb i .NET)

Har du inte förstått nånting av alla de inläggen jag gjort, om du kollar på sid 2. när man skapar ett typat dataset, skapas 2 saker, en XML fil för strukturen, och ett DataSet klass som också innehåller strukturen, Denna dataset klass behöver INTE en XML fil för att fungera, den är HELT fristående, den är klar att användas som en klass att kompilera till en .DLL, så dataset:et är redan klart och typat när man använder dataset:et skarpt.

Denna kostnad kan motsvaras med vad det tar att skapa ett objekt och fylla detta med data från DataTable (jag slipper ju skapa en dataset och låten detta leka runt med sina XML-Scheman)

Det är redan klart när man kör det skarpt, INGET XML SCHEMA BEHÖVS.

Du verkar tro att ingetting görs under ytan,

Det är ju du som tror det.