Hejsan

Jag bygger en applikation som lagrar och hämtar en
stor mängd data från en databas. För tillfället
använder jag mig av en SQL databas. Jag började
fundera lite igår och tänkte att man kanske skulle
flytta ut all databas kod till en DLL så att man
kan disstrubera stöd för flera olika databaser
vid senare tillfälle.

I min dll är det tänkt att jag skall använda ett
standard interface som jag använder till alla
database dll'er vare sig det är SQL, Oracle, Access
etc. Jag tror detta kallas för middle-ware och
används i n-tire com applikationer.

Är detta en bra lösning. Jag får iofs använda mig
av late binding (CreateObject) för att öppna
upp rätt dll, eftersom jag vill inte behöva
bygga in saker som t.ex Select Case satser för att
avgöra vilken "databas" modul jag skall använda.

Kan någon kommentera min tanke ?

Tack.

// Andreas Håkansson

jag tycker det låter som en utmärkt idé. Det finns massor av + i detta tänket. Jag kan snabbt dra några:

1. DLL-er arbetar snabbare speciellt om det är i kombination med ASP
2. Kan du även kasta in DLL:en i MTS så får du ytterligare kraft i form av last balansering.
3. Om du kör samma DLL för ett VB program och ASP behöver du bara ändra på ett ställe.
4. En bra dll- är som du säger också dynamisk - se min kurs VB/ADO där jag föreslår två databaser man kna öppna.

/Pelle

Gör ett gemensamt interface som du implementerar i alla dina olika databasaccess-DLLer, så kan du göra early-binding mot det.

så rätt så, men hur gör jag om jag vill leverera med en bunt olika dll'er för olika typer av database (SQL, Access, Oracle mm) så att användaren kan välja i inställningarna vilken typ som skall användas. Då måste jag vid uppstart kunna avgöra detta och ladda rätt dll automatiskt juh..

bye

skulle det inte funka om du byggde et fasadelement som drog i gång rätt dll vi rätt till fälle ??

jag håller presis på med det du tänker men jag har änå bara en sql server databas så för att kunna skriva till den går jag från asp till ett fasadelemen(dll) sen till en ext.dll som hittar alla dller sen till en tr(transaction) dll om jag vill skriva till databasen eller en Ntr(nontransction) om jag bara vill läsa. jag har byggda interface till alla dller utom fasadelementet där använder jag nått som kallas defalt interface

/Nicklas

Precis. Och anledningen till att man inte har något annat interface (än default alltså) till fasadobjekten är att ASP kan inte skapa ett objekt med early-binding, och då kan det ej heller använda andra interface.

Så, för att vidareutveckla mitt svar, skapa ett interface som definierar funktionerna för att läsa/skriva från databasen (vilken som), med funktioner typ GetSingle, GetList, Insert, Update, Delete eller vad du vill. Implementera sedan detta interface i dina databas-dll:er så att man anropar alla på samma sätt. I din klient kan du sedan skriva typ följande:

Dim Foo As IDataAccess
Dim DataSource As String
DataSource = ...läs inställning för databas...

Select Case DataSource
Case "SQLSERVER"
Set Foo = CreateObject("DataComp.CSQLServer")
Case "ORACLE"
Set Foo = CreateObject("DataComp.COracle")
Case "Access"
Set Foo = CreateObject("DataComp.CAccess")
End Select

Dim Data As ADOR.Recordset
Set Data = Foo.GetList(...)

Innebär inte din metod, just Late Binding?

Nej, variabeln skapas ju med early-binding mot interfacet.