[C#]verbinding met SQL-server of SQL Compact

[pkouwer]

Allereerst natuurlijk voor alles en iedereen de beste wensen voor het nieuwe jaar !!!

Ik ben voornemens een applicatie te maken die verbinding maakt met een database voor wat data-opslag. Op zich niet zo'n hele spannende toepassing, maar het is de bedoeling dat dit in twee uitvoeringen gemaakt wordt:

1) rechtstreekse verbinding met een SQL-server (express) database voor het real-time ophalen en verwerken van de benodigde data

2) offline verwerking in een lokale database, bij voorkeur SQL Compact.Er is in deze situatie geen netwerkverbinding aanwezig.

Nu wil ik tijdens een soort installatiewizard al aangeven welke database er gebruikt zal gaan worden.

Tot zover is er niets aan de hand. Maar wat ik niet wil is dat ik twee totaal verschillende programma's meot gaan ontwikkelen, ik wil dit dus in 1 applicatie houden.

Nu is mijn vraag: wat is hiervoor de meest gangbare/beste manier en hoe zouden jullie dit doen. Ik zit er aan te denken om twee class-file te hanteren (dbOnline.cs en dbOffline.cs) en op basis van de instelling de ene of de andere gebruiken.

[kutagh]

Is het daadwerkelijk nodig om voor dbOnline en dbOffline aparte klasses te maken? Voor zover ik weet zou het in principe hetzelfde moeten zijn, met verschillende connectie-informatie e.d., maar is de werking praktisch hetzelfde.

C# heeft ook een SQL library: System.Data.SqlClient (erop googlen zal wel tutorials opleveren). Als beide databases zich aan de standaarden houden zou je in principe alleen verschillende connection informatie nodig hebben, wat je op een andere manier kunt regelen dan 2 klasses voor online en offline (bijvoorbeeld een Dictionary van database en bijbehorende connection informatie).

[pkouwer]

in principe zou dit ook een optie zijn, maar ik ben een voorstander van Stored Procedures, hoewel ik weet dat dit niet in SQL Compact wordt ondersteund.Ik heb er een hekel aan om queries in de broncode toe te passen. SPROC vind ik (persoonlijk) fijner werken.


De twee verschillende classen wilde ik hanteren om e.e.a. gescheiden te houden.

[alwinuzz]

Hoe wil je stored procedures gaan gebruiken dan, alleen voor SQL Express?

Je geeft in de TS aan dat je niet twee verschillende programma's wil maken. Vervolgens denk je aan twee versies van je database-code (dbOnline.cs en dbOffline.cs)?

Het lijkt mij handiger om je queries maar één keer te schrijven, in de code van je programma. Dit kan bijvoorbeeld met wat kutagh zegt (System.Data.SqlClient), of met ander een framework/library die de database-specifieke dingen voor jou regelt. Zelf ken ik hiervoor alleen NHibernate, wat misschien overkill is als je fan bent van stored procedures...

Idealiter schrijf je je code één keer, en pas je alleen de connection string aan.

[dominic]

Ik kan goed begrijpen dat je stored procedures wil hanteren; de performance is zoveel beter vergeleken met dynamische t-sql queries waarbij steeds opnieuw door de engine een nieuw execution plan wordt gegenereerd.

Echter, de performancewinst komt wel met de nodige prijs; afhankelijkheid van de soort database-engine. Wanneer je zeker weet dat je voor een applicatie enkel en alleen een mssql database als primaire datasource gaat gebruiken, dan zou ik ook stored procedures hanteren. Je legt alleen uit dat de applicatie zowel offline als online -moet- werken, waardoor je een paar concessies zal moeten doen, waarvan de eerste het laten vallen van de wens voor stored procedures is.

Je omschrijft dat de database gebruikt wordt voor "wat dataopslag", een omschrijving waaruit de urgentie van een database-engine en de nodige performance niet echt naar voren komt. Een oplossing waarbij je de queries vanuit je code naar de betreffende tsql interpreter parsed lijkt me dan ook de beste oplossing.

Het enige waar je dan nog over in hoeft te zitten is:
1. Installation prerequisites
2. Connectionstrings
3. Injection proofing

..vervolgens kun je je dan gaan concentreren op de abstractielaag en dit als besloten beschouwen. Een laagje hoger gaan zitten zoals met nHibernate zal het abstractieproces versnellen, echter hou dan wel rekening met een klein verlies aan performance.

Edit: Hoe ieder de implementatie van de vertaling van data naar objecten en vice versa doet (DAL) verschilt erg, en zelfs iemand die zweert bij een bepaalde gang van zaken kan voor een betreffende applicatie van de lijn afwijken.

Ik hou er zelf altijd van om tastbare objecten in mijn code te hebben;
1. De constructor van een class (type data-object) handelt zelf de nodige inserts in de DAL af
2. De class heeft zelf .update/.remove methods met onderliggend de benodigde aanroepen naar de DAL

De DAL zelf kan weer van alles zijn; serializen naar files, databases etc.

In jouw geval zou ik aanraden een factory te schrijven welke jou voorziet van de geinstantieerde objecten. In deze factory zul je een switch moeten bouwen voor de connectie naar de betreffende databases.

[ Voor 21% gewijzigd door dominic op 01-01-2012 20:58 ]

[D-Raven]

dominic schreef op zondag 01 januari 2012 @ 20:42:
Ik kan goed begrijpen dat je stored procedures wil hanteren; de performance is zoveel beter vergeleken met dynamische t-sql queries waarbij steeds opnieuw door de engine een nieuw execution plan wordt gegenereerd.

Dit is deels achterhaald. In de nieuwere versie van MSSQL worden execution plans gecached, ook bij dynamische t-sql. Wat het beste werkt als je prepared statements gebruikt.

[alwinuzz]

Als je gewoon je queries schrijft met query parameters, is het execution plan steeds hetzelfde (+ voorkom je SQL injectie). Daar gaat je snelheidswinst.
In het algmeen dus, er zijn altijd uitzonderingen waar stored procedures écht handiger zijn.

Voor de TS nog een linkje naar een discussie over stored procedures / dynamische sql:

My conclusions:
- With Dynamically generated SQL, you'll have the logic working on the data in the relational model inside the application which should also embed that logic, as that logic is part of the application. You'll then also get a portable solution, which can target multiple databases, sometimes without even having to change anything.

Lijkt me helemaal wat je zoekt

Oh ja, bij de meeste software maakt de snelheid sowieso niets uit, als het maar snel genoeg is.

[ Voor 11% gewijzigd door alwinuzz op 01-01-2012 21:39 ]