Jag sitter och klurar på hur man smidigast separerar kopplingarna till databasen från resten av koden. Jag ska göra en applikation i C# som från början kommer jobba mot en Access-databas, men tanken är att denna ska kunna bytas mot en SQL-Server eller någon annan databas som kontaktas via en webservice utan att hela programmet behöver skrivas om. Finns det någon "standard" på hur man löser detta?

Jag har klurat en del på detta och det enda sättet jag kan komma på är att skapa en klass med en metod för varje dataset som behöver hämtas och sedan en metod dit man skickar datasetet när man har uppdaterat det och denna metoden uppdaterar sedan databasen med de ändringar som är gjorda. Jag antar att det underlättar att jobba med dataset eftersom de flesta griddar jag har kollat på i stort sett kräver att man jobbar med dem "databundna" och en stor den av redigeringen i applikationen kommer ske med olika griddar.

Är detta genomförbart? Är det ett helt vansinningt förfarande? Hur bör man göra istället? Har du en länk där dessa problem diskuteras tar jag gärna emot det! :)

/Johan

Du syftar på connectionsträngen eller? Den lägger du i så fall i web.config

<info>
<?xml version="1.0" encoding="utf-8" ?>
<configuration>

<appSettings>
<add key="ConnectionString" value="server=....uid=;pwd=;database=pellesoft" />
<add key="ConnectionStringLocal" value="server=..." />
</appSettings>
</info>

Sen finns en metod som hämtar dessa till koden:

<info>
Public Class dbfunctions

Shared Function GetConnectionString() As String

' returnerar olika connectionsträngar beroende på om man kör på localhost
' eller inte. Kör man på localhost används den lokala databasen på utvmaskinen.

If InStr(HttpContext.Current.Request.Url.ToString, "localhost") > 0 Then
GetConnectionString = ConfigurationSettings.AppSettings("ConnectionStringLocal")
Else
GetConnectionString = ConfigurationSettings.AppSettings("ConnectionString")
End If

End Function
</info>

Vet inte om det hjälpte - men kanske gav dig en idé.

Nej, det var tyvärr inte så jag menade. Dels är det Windows Forms-applikation och sedan är det betydligt mer som skiljer om man ansluter direkt mot databasen jämfört med om man ansluter via en webservice. Själva kopplingssträngen är det enkla i detta fallet.

/Johan

Hej

Tycker inte det är något fel alls att göra som du skriver, kanske en managerklass per tabell. Dessa managers kan du sedan kapsla in i en klass som hämtar rätt manager för att uppdatera den aktuella tabellen.

Om du tittar på lite olika O/R mappers så fungerar många på detta sätt. Du har ett interface utåt och sen en mängd olika klasser som vet hur varje objekt skall sparas och hämtas. På http://www.asp.net/Forums/Default.aspx?tabindex=0&tabid=1 så hittar du mer information, kika där och i synnerhet i arkitektur delen om du vill läsa mer. Ladda också ner en o/r mapper från sourceforge och kika på hur de har löst det.

Jag skulle skapat en plug-in arktiektur där alla data source klasser ärver ett och samma interface (ev basklass) med hjälp funktioner för att hämta data. Sedan skullel jag bygga "providers" som ärver interfacet och går mot olika datakällor.

Skulle även skapat en egen section handler i app.config dör jag enkelt specar vilken provider jag vill använda. Då om jag vill byta provider kan jag enkelt ändra det i en config fil istället för att ändra i koden och kompilera om allt.

/Fredrik Normén NSQUARED2

Att använda ett interface är väl rätt vettigt, det hade jag tänkt mig. Jag börjar få kläm på hur jag ska göra nu. Det jag är lite osäker på är om man ska "skicka tillbaka" datasetet som man har ändrat i till "providern" för att spara information till databasen. Jag har inte testat själv än, men det det borde väl gå utan problem? Alternativet är väl att skriva en wrapperklass per tabell, men det känns rätt jobbigt när det är många tabeller...

/Johan

En sak som jag gjorde när jag använde den metoden som jag skrev om innan, var att använda codesmith för att generera alla dataaccessklasserna.. Tror att där finns en template för detta i supportforumet, om inte så är där bra exempel på hur man löser det..

Var väldigt smidigt, bara välja vilka tabeller som man ville ha info från, köra codesmith och så hade man ett hyffsat dal..

http://www.ericjsmith.net/codesmith/forum/

Tack, det kanske kan vara något. Det är väl dax att testa de båda metoderna nu för att se vad som fungerar bäst i praktiken nu då...

/Johan

Johan, du verkar ha tur, 15seconds.com (fantastisk site) lade precis upp en sådan artikel i dagarna (27 jan).

Det gör precis det du talar om, kapslar in datahämtning, du kanske kan få lite ider därifrån oxo.
http://www.15seconds.com/issue/040127.htm

Dessutom har Bipin Joshi skrivit om MS Data Application Block för att passa till att passa med flera dber, oxo väldigt intressant http://www.dotnetbips.com/displayarticle.aspx?id=150

En annan kanonsida som tar upp samma problematik är sitepoint.com i deras artikel "unified data access in .NET", visserligen gjorde för asp.net men det borde inte vara omöjligt att anpassa mönstret till att omfatta windows forms (factory mönstret används)
http://www.sitepoint.com/article/1253

Tack, det var intressanta artiklar, speciellt den från 15seconds! Även om detta inte är mitt grundproblem så är det användbart för vissa delar, samt säker till framtida applikationer. Dessutom frågade min kollega mig om jag hade en bra lösning på detta problemet nyligen, så det är en perfekt länk att skicka till honom! ;)

/Johan

För er som är lite nyfikna på hur man kan använda olika providers i nästa verision av ADO.Net ta då en titt på mitt "Data Access Applikations block" workspace:

http://www.gotdotnet.com/Community/Workspaces/Workspace.aspx?id=65fa26c3-a62a-49d6-895d-422272e53a0c

Skulle även rekommendera er att gå till denna site:

http://www.gotdotnet.com/Community/Workspaces/Workspace.aspx?id=c20d12b0-af52-402b-9b7c-aaeb21d1f431

Där hittar ni en utveckling av Microsofts Data Access Applikations block, där providers kan definieras i web.config och enkelt byta ut.

/Fredrik Normén NSQUARED2