Discussion :

[dachir]

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.

[SaumonAgile]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[dachir]

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.

[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).

[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.

[SaumonAgile]

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.