Inom den organisation jag jobbar (kommun) finns ett antal olika system/databaser, där utveckling främst sker mot Oracle och Access (jaja) men även MS SQL Server mfl. kan förekomma.

Idag kör jag med en generell databasklass som jag kan återanvända i många projekt. Funderar däremot att bygga ut den klassen något och köra den som en WebService. Dvs. den får fungera som en "komponent" där samtliga applikationer/tjänster som behöver hämta data från någon databas använder sig utav.

Rättare sagt kanske det måste bli två-tre WebServices på samma server. En for Oracle, en generell OleDb och kanske en ODBC.

Är detta en bra idé?
Underhållsmässigt känns det som om det skulle vara smidigt. Men prestandamässigt kan det kanske bli problem?

Som sagt, behöver gärna lite feedback...

Många webservicar blir det.. Sen måste klienten som anropar veta vilken databas som är aktuell. Tänk om ni flyttar data från Access till Oracle, då måste alla klienter uppdateras vilket kan bli bökigt (beroende på hur era system ser ut).

Vad är det för fel med databasklassen du har? Eventuellt kan väl en webservice använda sig av den och själv hålla reda på vilken databas som är aktuell.

Du kanske vill se om en kund finns i systemet, fråga då webservicen som talar om det för dig. Du behöver inte veta om kunden är sparad i access eller oracle. Byter ni databas så kan ni ha kvar alla anrop som ställer samma fråga. Då ändrar ni bara i webservicen när den talar med databasen.

En webservice skall inte hålla på med generella DAL prylar. Just av prestanda skäl.

Däremot skulle man kunna tänka sig att bygga en produkt tjänst, en kund tjänst osv som man sedan återanvänder i hela it-miljön.

Tycker som Patrik, WS ska användas till specifika delar som man gärna vill återanvända, men inte som DAL-backbone i ett system med prestandakritiska delar..

Tänk "tjänst som erbjuder specifik information", oberoende av DB osv.

T.ex. Alla produkter i "Katergori X"
En sådan lista kan erbjudas av en WS i form av ex. vis Dataset.
Med fördel har du samtidigt en mekanism i din presentationslager t.ex ASP.NET applikationen som cachar dataset "lokalt" (så länge som det är lämpligt att göra det...)

Nu kan du använda produktlistan både för den interna produktadmin-applikationen och för webbsajten som visar upp produkterna.

Prestandamässigt är det mycket bra att slippa slå upp produktlistan i databasen vid varje anrop.
Om den inte ständigt förändras bör det inte vara några problem.

Jag kunde inte säga det bättre själv, "ler". Jag var och lyssnade på ett föredrag i höstas där ett företag hade byggt sitt DAL med webservices då de hade många klienter med handburna enheter som då kunde ansluta mot databasen på samma sätt som applikationer för webb såsom forms. Den slutsats de drog i det projektet var som sägs, det går aldeles för långsamt att använda och webservices är inte ännu tillräckligt optimerat för att kunna hanteras som "snabba" transktioner.

Skapa i stället ett class-library som innehåller de funktioner som behövs för datalagret. Därefter kan du distribuera denna dll till de övriga applikationerna så tror jag du får den största effekten och minsta huvudvärken. Lycka till!

Tackar för svaren! Tillbaka till GACen igen...
Varför ska man pilla på saker som redan funkar ;)

Bra förslag att använda sig av databasklassen i WS för att hämta viss specifik information som återkommer i applikationer och webbsiter. När jag tänker efter var det nog mer ett sådant komplement jag behöver.

Och om jag fattat rätt så skall det räcka med att eventuellt ändra i min databasklass för att även de WS jag bygger skall funka. Alltså om man byter databasleverantör, gör tabellomstruktureringar etc. vill säga?
Kan vara för att det är sent på kvällen, men jag är ändå inte riktigt med på banan hur man tänker sig göra WebServices oberoende av DB...(?)

En Webservice returnerar ju bara XML.
Som konsument av en WS har du inget intresse av vilken DB som ligger bakom. Om det ens är en DB. Det kan ju lika gärna varar en txt, xml eller Excel-fil som är den bakomliggande datakällan.
Du kanske vill komma igång med nåt snabbt, du gör en Access-databas. Sen när konsumtionen av din WS ökar kan du skala upp till SQL server utan att konsumenteran ens behöver få reda på det. De har ju samma SOAP-interface mot din WS.

Javisst är det så...
(jag är vaken nu)

En relaterad fråga: DB-anslutningarna i ADO.NET poolas ju... och jag antar att poolningen sker per applikation. Måste man alltså om man använder sig av flera olika databaser göra flera olika applikationer/web services i DAL för att poolningen ska fungera eller går det att gå runt?

Njae, ADO.NET skapar en connectionpool per databas, så det behöver du inte tänka på.

Ett tillägg om Connectionpooling: Under förutsättning att du alltid använder samma connectionsträngar också bör tilläggas. Om flera olika används skapas en pool för varje, ex om man har olika användarnamn och lösenord till samma databas.