[C#/ADO.NET] Machine onafhankelijke databaseverbinding

[dtech]

Hallo,

ik wil een (C#) tooltje herschrijven zodat het behalve met SQL Server databases ook met SQLite en MySQL databases werkt.
Sinds ADO.NET 2.0 bevat ADO.NET de benodigde classen om generieke databasecode te schrijven. Ook zijn er prima providers voor zowel SQLite (en er zijn er nog wel meer)) als MySQL.

Het enige waar ik niet helemaal uit kom is hoe ik ervoor kan zorgen dat het programma werkt op elke computer, zolang die maar het .NET framework heeft. Is het genoeg om gewoon de juiste twee dll's te referencen in Visual Studio? Ik lees namelijk overal dat DbProviderFactory zijn informatie uit machine:config haalt (waar ik sowieso weinig over kan vinden) en ik neem aan dat deze pas aangevult wordt bij de installatie van de provider.

Ik heb ook wat gelezen over Linq To SQL (al wordt dat nog niet 100% ondersteund door Mono) en vind het er veelbelovend uitzien. Het enige waar ik niet achter kan komen is hoe/of het werkt met andere databases dan MS SQL, heeft iemand daar wat over te zeggen?

[alt-92]

dtech schreef op zaterdag 01 mei 2010 @ 12:54:

Het enige waar ik niet helemaal uit kom is hoe ik ervoor kan zorgen dat het programma werkt op elke computer, zolang die maar het .NET framework heeft.

Stating the obvious:
Er is niet slechts één 'Het .NET framework'.

Er zijn drie current versies die je sowieso zal tegenkomen. Aan jouw de keuze om de lowest common denominator te vinden die je gewenste ondersteuning biedt.

[DutchCommando]

dtech schreef op zaterdag 01 mei 2010 @ 12:54:
Ik heb ook wat gelezen over Linq To SQL (al wordt dat nog niet 100% ondersteund door Mono) en vind het er veelbelovend uitzien. Het enige waar ik niet achter kan komen is hoe/of het werkt met andere databases dan MS SQL, heeft iemand daar wat over te zeggen?

Volgens mij is er geen ondersteuning voor andere databases. Andere Object-relational Mappers hebben hier wel ondersteuning voor. Maar dat is hier op GoT al vaker besproken.

Stel jezelf vooral de vraag of het gebruik van een ORM mapper zin heeft voor je applicatie. Een ORM kan zich al vrij snel terug verdienen, maar als je applicatie slechts bestaat uit enkele queries dan kan je deze ook gewoon los uitprogrammeren (1, 2).

Zelf heb ik twee jaar geleden een SQL generatie module geschreven voor zeven databases. De moeilijkheid zit hem zeker niet in de ADO.NET 'abstractie' (zo lek als een mandje natuurlijk) maar vooral in de minieme verschillen van SQL-syntax en data types.


1. http://martinfowler.com/eaaCatalog/transactionScript.html
2. http://martinfowler.com/eaaCatalog/tableModule.html

[ Voor 48% gewijzigd door DutchCommando op 01-05-2010 13:56 ]

[dtech]

@alt-92
True, maar aangezien de oorspronkelijke versie geschreven was in .NET 2.0 ga ik gewoon verder in .NET 3.5. Ook is dit framework op bijna elke (windows) computer aanwezig.

@DutchCommando
Als je toch bezig bent kun je net zo goed gelijk omgaan naar een ORM. Het programma is wel netjes geschreven in MVC dus een enorm probleem moet het niet zijn. Natuurlijk is de abstractie van ADO.NET niet super maar aan wat standaard functies (select, update, dete, group, join, where etc.) en datatypen (int32, varchar/string, float, datetime) kom ik al een heel eind.

@LINQ
Mono ondersteund LINQ overigens wel (alhoewel nog niet compleet) voor diverse databases, dus het kan in ieder geval wel.

Er is ook nog DB_Linq, maar ik ben nog een beetje aan het uitzoeken hoe compleet die is, hij is ook alweer een tijdje niet geupdate

@topic
Weet iemand nou hoe ik de DbConnection factory onafhankelijk van de PC Mysql support kan geven?

[ Voor 15% gewijzigd door dtech op 01-05-2010 15:38 ]

[DutchCommando]

dtech schreef op zaterdag 01 mei 2010 @ 15:34:
@DutchCommando
Als je toch bezig bent kun je net zo goed gelijk omgaan naar een ORM.

Nee, want het schema van de database is van tevoren niet bekend.

dtech schreef op zaterdag 01 mei 2010 @ 15:34:
@topic
Weet iemand nou hoe ik de DbConnection factory onafhankelijk van de PC Mysql support kan geven?

De MySQL Connector/Net meeleveren?

[dtech]

dtech schreef op zaterdag 01 mei 2010 @ 12:54:
Is het genoeg om gewoon de juiste twee dll's te referencen in Visual Studio? Ik lees namelijk overal dat DbProviderFactory zijn informatie uit machine:config haalt (waar ik sowieso weinig over kan vinden) en ik neem aan dat deze pas aangevult wordt bij de installatie van de provider.

[DutchCommando]

Waar lees je dat? Plaats gewoon de juiste provider in je App.config of Web.config en lever de DLL mee.

[dtech]

O.a. Op MSDN (toch niet de minste bron zou je zeggen)

Ik ga App.config even proberen, maar ik vind het wel raar dat het ondanks dat het artikel "Using Application Configuration Files ..." als kopje bevat er daarover niks staat

[dtech]

In App.config includen werkte inderdaad. Voor mensen die dit topic nog vinden: zet <system.data>Jouwprut</system.data> direct voor </configuration, als laatste dus; anders klaagt Visual studio als je settings gedefinieerd hebt. Ook was de string die je nodig had enigszins lastig te vinden:

code:

<remove invariant="MySql.Data.MySqlClient" />
      <add name="MySQL Data Provider" invariant="MySql.Data.MySqlClient"
           description=".Net Framework Data Provider for MySQL" type="MySql.Data.MySqlClient.MySqlClientFactory, MySql.Data" />

Het enige waar ik nog niet achter ben is of het mogelijk is om, als het geinstalleerd is, de "native" (dwz: op de computer geinstalleerde) provider te gebruiken i.p.v. altijd de .dll en/of afhankelijk van de versie (x86/x64) van het .Net framework een andere .dll te includen.

Dit is bijv. bij SQLite van belang. De SQLite provider biedt drie versies aan: "Any", "x86" en "x64". Any is in managed C++ geschreven en is relatief langzaam (en heeft op linux de sqlite lib nodig) maar werkt wel op Mono en alle versies van het .Net framework. De x86 resp. x64 versies van de .dll bevatten de native (C) Sqlite library meegecompiled en zijn dus een stuk sneller.

[ Voor 11% gewijzigd door dtech op 03-05-2010 22:27 ]