Behöver råd hur man på ett smidigt sätt hämtar data från flera olika databaser.
I detta fall handlar det om två tabeller från två olika databaser som skall joinas. En databasen är en Accessbas och den andra är en Oraclebas som delar viss information. En gemensam nyckel finns mellan tabellerna.

En (enkel) lösning skulle kunna vara att "länka" in Oraclebasens tabell till Accessbasen eftersom det endast handlar om read-only av Oraclebasen. Men jag vill inte lösa det på detta sätt av vissa anledningar. Vill att den logiken skall byggas in i applikationen.

Funderar på att i mitt databaslager hämta data från de två oilka datakällorna till ett DataSet. Sedan kör jag själva joninen i DataSet:et.

Kör med en form av Generics där resultatet ska sedean returneras "uppåt" till BL i en IList<T>.

Så min idé är att jag gör joinen i ett DataSet i databaslagret (eftersom det är smidigt att göra detta i ett DataSet), loopar sedan igenom DataSet:et och returnenerar en IList<T> som bygger min Business Entitet.
Är detta en bra väg att gå???

Eller så hämtar du bara datat i två olika readers och kopplar samman dem när du läser upp det. Finns ingen direkt vinst för det här scenariot med data set.

Det vore en bra lösning då jag fyller på all annan data från databaserna med DataReaders. Men jag är inte riktigt med på hur man gör en inner join mellan två readers? Blir det till att för varje rad i den ena readern loopa igenom den andra readern för att se om det finns någon matchning?

Du (eller någon annan) råkar inte ha något exemel att visa (länk, kod)?

Du gör typ så här:

        public class Category {
            public int Id;
            public string Name;

            public Category(IDataRecord record) {
                Id = Convert.ToInt32(record["id"]);
                Name = Convert.ToString(record["name"]);
            }
        }
        
        public class Product {
            public string Name;
            public Category Category;

            public Product(IDataRecord record, Category category) {
                Category = category;
                Name = Convert.ToString(record["productname"]);
            }
        }

        public static IList<Product> GetAllProducts() {
            SqlDataReader categoryReader = GetCategoryReader();
            Dictionary<int, Category> categories = new Dictionary<int, Category>();

            while (categoryReader.Read())
                categories.Add(Convert.ToInt32(categoryReader["id"]),
                               new Category(categoryReader));

            categoryReader.Close();

            SqlDataReader productReader = GetProductsReader();

            IList<Product> products = new List<Product>();
            while (productReader.Read()) {
                Category category = categories[Convert.ToInt32(productReader["categoryId"])];
                Product product = new Product(productReader, category);
            }
            
            productReader.Close();

            return products;
        }

Tack för svaret. Den metoden var bra att spara för framtida bruk.
Jag löste det på likande sätt, dvs. fyllde först det ena IList:en i "GetAllProducts" och joinade med den andra IList:en. Det blev enklast så för att det skulle passa in i min befintliga kod.

Joinen som skulle göras var av typen "right outer join" vilket gjorde saker och ting bökigare...

I efterhand uppkom även önskemål (som ska följas) att även hämta in information från en tredje källa. Som om vi följer exemplet ovan finns genomgående en productID (nykel) från alla tre datakällor. Nu ska alltså data joinas ihop från Oracle, Access samt filbaserad data - bildfiler/pdf:er som turligt nog bär productID i sitt filnamn. Sedan skall även klabbet knytas till ett geografiskt objekt men det är en annan femma...

Har försökt hitta något läsvärt i bokform och på nätet om hur man bör tänka/designa när man vill jobba med data från flera ställen (databaser etc). Att hitta information hur man mappar data på olika sätt från EN databas finns det gott om. Både för OOP och DDD med DataSet, Cumstom Entities Object etc etc...

Hur bör man tänka när man bygger sina domän entiteter/objekt, exempelvis Products som i applikationen ska spegla produktinformaion i en form som inte finns någon annanstans än i applikationen. Dvs. databas och databasmodellerna lever sitt "eget" liv och är egentligen inte knutna till själva utvecklingen av applikationen. Dom speglar bara delvis domänobjektet (slarvigt ordval).

I detta fall kan jag inse, av det lilla jag läst, att bygga utifrån domänen (typ DDD) lämpar sig rätt väl jämfört med klassiskt OOP? Cyklar jag ute på hal is då eller...

Det förvånar mig i alla fall att jag inte hittar mycket matnyttigt att läsa om detta för problemet jag beskriver lär knappast vara nått nytt. Antar att jag söker på fel sätt.

ADO.Net Entity Framework som kommer under 2008 kommer vara en bra lösning på ditt problem. Där kan du skapa din modell och mappa entiteter mot flera datakällor etc.

OOP och DDD är inte riktigt samma sak, många tror det för det påminner så mkt om det.

"Domain-driven design is not a technology or a methodology. It is a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains." - Eric Evans

"OOP is a programming paradigm that uses "objects" to design applications and computer programs. It uses several techniques from previously established paradigms, including inheritance, modularity, polymorphism, and encapsulation."

Jag har byggt npgra lösningar där jag hämtar data från olika datakällor, tex där entiterar fylls från både XML och Databas. Eftersom det inte finns något ramverk som passar mig för detta, så har jag fått lösa det själv. I mina Repositories så ser jag till att först göra en data access mot tex en databas, få ut en reader och fyller upp min entitet med den data jag kan plocka ut från databasen. Nästa steg är att hämta datan från XMLen, ganska enkelt, men varför inte "keep it simple stupid" ;) (Jag brukar använda factories för detta). Att skapa ett ramverk som gör själva mappningen mot olika datakällor är inte så svårt, men sedan tillkommer Unit of Work (UoW), Identity map, change tracking etc. Jag är inte så haj på alla ramverk men det finns nog några som låter dig registrera din entitet mot en UoW.

/Fredrik Normén
ASP.Net MVP - Cornerstone
blog: http://fredrik.nsquared2.com

"Domain-driven design is not a technology or a methodology. It is a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains." - Eric Evans
Undra var gränsen för complicated domains går...? ;)


Beställde precis den här boken:
http://blogg.joakimsunden.se/2007/01/applying-domain-driven-design-and.html
Hoppas den är bra.

Jimmys bok är jättebra,

Men jag föreslår att du är lite orienterad runt patterns och DDD innan du läser den. Annars kan det bli lite tungt på en gång.

Björn:

Här är lite tips på bra böcker som kan underlätta innan du läser Jimmys bok (Som ett tillägg till Patriks inlägg ;)):

Domain-Driven Design - Eric Evans

http://www.amazon.com/exec/obidos/ASIN/0321125215/qid%3D1087633042/sr%3D11-1/ref%3Dsr_11_1/103-7309157-9153431

Patterns Of Enterprise Application Architecture - Martin Fowler
http://www.martinfowler.com/books.html#EEA

Som ett litet extra tips på en mkt bra bok som ska även finnas med C# kod istället för Java etc:

Agile Software Development, Principles, Patterns, and Practices - Robert C. Martin
http://www.amazon.com/exec/obidos/tg/detail/-/0135974445/qid=1096614822/sr=8-4/ref=pd_csp_4/102-9178777-1113747?v=glance&s=books&n=507846

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

Fasen, jag måste ju hinna jobba också... ;)
Att bygga nått skarp med DDD ligger ändå nått år bort skulle jag tro.

Tack för lästipsen. Ska ändå försöka klara mig med boken jag köpt. Det finns mycket att läsa på nätet nu när jag vet vad jag ska söka efter.