Se connecter à Sql Server ou Oracle dynamiquement

Version imprimable

06/10/2007, 11h48
dachir

Se connecter à Sql Server ou Oracle dynamiquement

Bonjour,
Je développe une application de Gestion pour une société. Le problème, c'est que certaines filiales de cette société utilise Sql Server alors que d'autres utilise Oracle comme SGBD. Vu que ça bataille dur entre les développeurs pour trancher sur le SGDB à retenir, j'aimerais proposer une architecture 3 tiers qui s'affranchit de la BD dans la couche d'accès aux données en utilisant Vb.net comme outils de développement. Malheusement je n'ai qu'une idée vague de comment procéder. Je suis sur que vous pouvez m'aider.
Merci de votre collaboration.

Dans un fichier de configuration externe, tu stockes la connectionstring ainsi que le type de base.
Tu crées une méthode qui te renvoie une connexion à ta source de données. Voici une ébauche :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
public class DataProvider
    {
        // Ici au lieu de mettre "System.Data.SqlClient", tu vas chercher la valeur dans un fichier de configuration.
        private static DbProviderFactory factory = DbProviderFactories.GetFactory("System.Data.SqlClient");
 
        public static DbConnection CreateConnection()
        {
            DbConnection connection = factory.CreateConnection();
            connection.ConnectionString = ConfigurationManager.ConnectionStrings["MyConnectionString"].ConnectionString;
            connection.Open();
 
            return connection;
        }
 
        public static DbCommand CreateCommand(string commandText)
        {
            DbCommand command = CreateConnection().CreateCommand();
            command.CommandText = commandText;
 
            return command;
        }

Avec cette approche, tu n'as plus de référence spécifique à la source de données.

08/10/2007, 14h45
dachir

Ok La connexion n'est plus un problme, mais!!!!!

Maintenant que la connexion aux diverses bases de données n'est plus un problème, dois je placcer mes procédures stockées et fonctions et triggers dans un assembly? est ce qu'il n'y aura pas de problème de syntaxe entre le PL/Sql et le TSql?
Merci de votre collaboration.
08/10/2007, 14h48
SaumonAgile

Tu peux utiliser un fichier différent pour stocker les procédures, vu que je pense que tu les charges d'un fichier externe. Pour les triggers, tu peux en effet partir sur la solution d'un assembly différent chargé dynamiquement lors de l'éxecution (toujours en fonction de ce même paramètre de config).
08/10/2007, 15h58
dachir

wow!!!

Merci SaumonAgile. Tes réponses sont vraiment agiles. Je crois que j'ai eu solution a mon problème. Au cours de l'implémentation, si je rencontre un problème j'espère que tu seras dans le coin et que tu agiras avec autant d'agilité a mon égard.
Mais dis moi "Arretes de courrir com ça, tu vas te fatiguer."

Juste une derniere question: pourquoi seulement les triggers ds un assembly?
Merci.
08/10/2007, 16h11
SaumonAgile

Citation:

Envoyé par dachir

Merci SaumonAgile. Tes réponses sont vraiment agiles. Je crois que j'ai eu solution a mon problème. Au cours de l'implémentation, si je rencontre un problème j'espère que tu seras dans le coin et que tu agiras avec autant d'agilité a mon égard.
Mais dis moi "Arretes de courrir com ça, tu vas te fatiguer."

Juste une derniere question: pourquoi seulement les triggers ds un assembly?
Merci.

En fait dans l'assembly, tu devrais mettre tout ce qu'il n'est pas possible de définir dans le fichier externe, et utilisable par un système générique.
08/10/2007, 16h55
dachir

Citation:

Envoyé par SaumonAgile

En fait dans l'assembly, tu devrais mettre tout ce qu'il n'est pas possible de définir dans le fichier externe, et utilisable par un système générique.

Excuse-moi de te fatiguer plus que tu ne l'es déjà (je kif trop ton avatar). mais je reprécise ma question: pourquoi n'est-il pas possible de mettre un trigger das un fichier externe???
Merci.
09/10/2007, 00h11
cinemania

alors en fait tu peux... si tu dispose de plusieurs fichiers externes... 1 par type de SGBD.
la raison ? et bien c'est très simple... la syntaxe pour déclarer un trigger n'est pas la même sur Oracle et sur SQL Server, pour ne citer que ces deux là.
Au même titre qu'il y a une différence dans le texte des procédures stockées en Pl/SQL et T-SQL.

Moi j'ai encore d'autres problèmes... je dois récupérer des données qui m'oblige à faire une assembly spécifique pour chaque base de données, car je dois entre autre récupèrer le profile complet de procédures, functions, et les exécuter en mode plan pour extraire la forme du résultat.
et comme bien entendu la technique entre oracle et sql server est radicalement différente pour extraire toutes ses données...

mais bon.
09/10/2007, 08h04
SaumonAgile

Citation:

Envoyé par dachir

Excuse-moi de te fatiguer plus que tu ne l'es déjà (je kif trop ton avatar). mais je reprécise ma question: pourquoi n'est-il pas possible de mettre un trigger das un fichier externe???
Merci.

Oublie les triggers et base toi uniquement sur le constat : "Si la fonctionnalité (procédure, fonction, triggers, etc) n'est pas définissable dans un fichier externe, alors il faut songer à utiliser une assembly spécifique."
09/10/2007, 09h17
cinemania

justement, les triggers, commes les procs stoc ne sont pas commun aux sgbd (je te parle meme pas de ceux qui ne les supportes pas...)
de plus il ne s'agit pas de code évalué à chaque lancement de l'application, mais seulement à son installation (voir premier lancement)
il est donc logique de mettre tout le texte déclaratif dans un fichier externe, en plus ca en rend la maintenance, l'ajout de texte ... plus facile sans pour autant "recompiler" l'application.
Si tu détecte un bug dans ton appli coté SQL, suffit de relancer les scripts SQL et zou... si t'intègre dans une assembly meme spécifique... faudra recompiler l'assembly et gérer toi meme l'intégration dans le SGBD.

pour ce qui est du code à mettre dans des assembly distinctes que tu charge au besoin... c'est le code qui n'appartient pas à la base de donnée, mais qui varie en fonction de celle-ci par exemple, ou qui varie en fonction du contexte d'utilisation.

Remarque : avec l'apparition de sql2005 et bientot 2008, il est possible d'écrire tes procédures en autre chose que tu T-SQL, comme en les écrivant en .NET en hostant une assembly. Dans ce cas précis, tu peux si tu as plusieurs versions ou plusieurs sgbd différents supportant tous l'intégration .NET créer des assembly spécifiques avec le code spécifique à chacun.
10/10/2007, 11h56
dachir

Citation:

Envoyé par cinemania

justement, les triggers, commes les procs stoc ne sont pas commun aux sgbd (je te parle meme pas de ceux qui ne les supportes pas...)
de plus il ne s'agit pas de code évalué à chaque lancement de l'application, mais seulement à son installation (voir premier lancement)
il est donc logique de mettre tout le texte déclaratif dans un fichier externe, en plus ca en rend la maintenance, l'ajout de texte ... plus facile sans pour autant "recompiler" l'application.
Si tu détecte un bug dans ton appli coté SQL, suffit de relancer les scripts SQL et zou... si t'intègre dans une assembly meme spécifique... faudra recompiler l'assembly et gérer toi meme l'intégration dans le SGBD.

Merci à tous.
Il est vrai qu'utiliser un fichier externe rend la mainetnance plus facile, mais je me demande si cela ne pose pas un problème en terme de sécurité. un fichier compilé renforce un peu plus la sécurité du fichier source. Dans tous les cas, j'ai bien compris. Si j'ai une autre préocuupation, je saurai à quelle porte frapper.
19/10/2007, 11h23
ccambier

Bonjour,
qu'est-ce que tu entends par sécurité? à ce niveau ça ne pourrait être que des erreurs d'execution de script !!!
ce qu etu peux faire c'est un petite application légère pour mettre à jour tes DB
et là ce que tu auras c'est uniquement à choisir la DB et les scripts que tu utilisera seront stocké dans un fichier binaire (p-e) ou dans une autre source de donnée à laquelle l'utilisateur n'aura pas accès directement.

déjà ça limitera les risques d'erreur dans l'execution des scripts et s'il y a un update ce sera très facile pour l'utilisateur de mettre à jour sa db

Reste à voir si c'est vraiment necessaire...