Discussion :

[Pete]

Helle evry body !
Dans le (très interessant) tuto de R. Chapuis situé ici :
http://nx.developpez.com/Articles/DAC/#s5
Dans le paragraphe 5 : Factoriser les méthodes d'accès aux données.
Dans chacun des exemples donnés, la chaine de connexion n'est pas spécifiée dans la ligne

Code :

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

using ( Connection = this.CreateConnection() )

est ce une erreur ?

Si oui, comment revenir à la méthode d'utilisation souhaitée, à savoir :

Code :

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

1
2
3
4
public int SaveData(string query)
{
 return DataProviderFactory.GetInstance().ExecuteNonQuery(query):
}

C'est à dire sans reprécisier la chaine de connection. Faut il la sauver quelque part dans l'objet? Faut il la repréciser à chaque fois qu'on veut utiliser une des méthodes du paragraphe 5 ? Ou faut il leur passer un IDbConnection ?

Merci de vos

[neo.51]

Salut,

Bon voici comment j'ai abordé la chose :

1)Définir une interface IProviderInfo qui donne ça :

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
public interface IProviderInfo
	{		
		//Nom du provider
		string ProviderName
 
		//mot de passe
		string Pass	
 
		//Login
		string Login
 
		//servername/TNS/chemin de fichier suivant les cas
		string Server
 
		//caractère utilisé pour les parameters
		char ParameterChar
 
	}

2)Ensuite j'ai fais une fabrique de providerInfo, sur le même principe que la fabrique de DataProviders :

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
 
		protected static IProviderInfo _theUniqueInstance = null;	
 
		//singleton pour n'initialiser qu'une instance de ProviderInfo
		public static IProviderInfo GetInstance()
		{
			if (_theUniqueInstance == null)
			{
				//on récupère le TypeProviderInfo du fichier de configuration 
				NameProviderInfo = ConfigurationSettings.AppSettings.GetValues("TypeProviderInfo")[0];
				switch (NameProviderInfo)
				{
					case "BasicXml" :
						_theUniqueInstance = new ProviderInfoTypes.BasicXmlProviderInfo();
						break;
					default :
						throw new Exception("Le provider d'information sur les paramètres du SGBD n'est pas supporté. InfoProvider : " + NameProviderInfo);
				}
			}
			return (_theUniqueInstance);
		}

Dans le fichier de configuration de l'applis on rajoute une key "TypeProviderInfo" qui définira la classe qui va récupérer les infos.
Ma classe BasicXmlProviderInfo va cherche un bon vieux xml où tout est stocké en clair. Mais si demain je veux aller chercher les données dans la base de registre, dans un fichier texte, un fichier crypté, un compte active directory, etc... Il me suffit d'implémenter une classe implémentant l'interface IProviderInfo, de la rajouter à ma factory de providerInfo, changer la clé TypeProviderInfo de mon fichier de configuration et le tours est joué. ça c'est le coté évolutif, pour les perfs, biensur un sigleton pour pas qu'on aye instancier une nouvelle classe et rerécupérer providerInfo à chaque fois qu'on fait une connection

3)Dans la factory de DataProvider :

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
22
23
24
25
26
public static DataProvider GetInstance()
		{
			if (m_instance == null)
			{
				DataProvider Instance;
				IProviderInfo myProviderInfo;
				myProviderInfo = ProviderInfo.GetInstance();
				switch (myProviderInfo.ProviderName.ToUpper())
				{
					case "ACCESS" :
						Instance = new Providers.DataProviderAccess(myProviderInfo);
						break;
					case "SQLSSERVER" :
						Instance = new Providers.DataProviderSqlClient(myProviderInfo);
						break;
					case "ORACLE" :
						Instance = new Providers.DataProviderOracle(myProviderInfo);
						break;
					default :
						Instance = null;
						break;
				}
				m_instance = Instance;
			}
			return (m_instance);
		}

J'ai ajouté un singleton pour éviter de recréer un provider à chaque fois, et tous mes dataProviders ont besoin d'un Provider info dans le constructeur. Ensuite le constructeur créera la chainne de connection (avec stringBuilder of course ) et la stockera dans un attribut privé de la classe.

Voilà comment je vois la bête Ma solution n'est surement pas parfaite. Notes au passage que je ne peux pas faire de multi-SGBD dans une même applis. Mais en contre partie j'ai un code ultra simplifié quand j'utilise mon DAC (je ne me soucis plus jamais du provider et de la chainne de connection).

Bon pas évident d'expliquer ça sur le forum .R. Chapuis a prévu une suite trés technique de son article (transactions, procédures stockés, etc...), j'en ai déjà discuté avec lui et suivant l'orientation de ses article je me lancerai dans une suite plus "terre à terre" pour évoquer les problème de datareader, dataadapter et de parameters



A suivre donc

[Pete]

Ensuite le constructeur créera la chainne de connection (avec stringBuilder of course )

Interessant ton IProviderInfo, et bien souple. Par contre je ne vois pas comment tu obtient ta chaine de connection ? Tu n'as pas forcément tous les paramètres dispo dans le IProviderInfo, non? Ou peut être t'as plus de détails stockés dans le fichier XML ? (pour cet exemple)

et la stockera dans un attribut privé de la classe.

ça me va bien aussi, ça évite de se la trimbaler partout !

Notes au passage que je ne peux pas faire de multi-SGBD dans une même applis. Mais en contre partie j'ai un code ultra simplifié quand j'utilise mon DAC (je ne me soucis plus jamais du provider et de la chainne de connection).

Si tu concerves une régérence sur le DataProvider et que tu n'appelles plus GetInstance() à chaque fois ton code est aussi simple. Et tu peux alors faire facilement du mutli-SGBD, en enlevant le singleton et en rajoutant 1 ou 2 paramètres, non?


C'est dans ce DAC que tu à fait ton DataReader : http://blog.developpez.com/index.php...&c=1&tb=1&pb=1 ?
C'est une bonne idée ce truc des champs indexés , dommage que je n'en pas l'utilité dans mon appli... Ca vaudrait le coup de faire pareille sur des DataRow?

[neo.51]

Ensuite le constructeur créera la chainne de connection (avec stringBuilder of course )

Interessant ton IProviderInfo, et bien souple. Par contre je ne vois pas comment tu obtient ta chaine de connection ? Tu n'as pas forcément tous les paramètres dispo dans le IProviderInfo, non? Ou peut être t'as plus de détails stockés dans le fichier XML ? (pour cet exemple)

En fait pour l'instant c'est simplifié et fait pour créer des chainnes de connection minimales exemple pour le provider access :

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
internal DataProviderAccess(IProviderInfo myProviderInfo) : base()
		{
			try
			{
				strConn = new StringBuilder("Provider=Microsoft.Jet.OLEDB.4.0;Password=");
				strConn.Append(myProviderInfo.Pass);
				strConn.Append(";User ID=");
				strConn.Append(myProviderInfo.Login);
				strConn.Append(";Data Source=");
				strConn.Append(myProviderInfo.Server);
				this.ConnectionString = strConn.ToString();
				this.parameterChar = myProviderInfo.ParameterChar;
			}
			catch (Exception Ex)
			{
				throw(new Exception("Impossible de créer la chainne de connection OleDB", Ex));
			}
			this.parameterChar = myProviderInfo.ParameterChar;
		}

je pensais rajouter un attribut "ParamConnectionString" dans mon ProviderInfo manière d'avoir un champ texte libre pour ajouter des paramètres pour une chainne de connection plus complexe. Je compte étoffer un peu cette partie, mais c'est pas le plus urgent pour l'instant.

Si tu conserves une régérence sur le DataProvider et que tu n'appelles plus GetInstance() à chaque fois ton code est aussi simple. Et tu peux alors faire facilement du mutli-SGBD, en enlevant le singleton et en rajoutant 1 ou 2 paramètres, non?

Je ne me suis pas penché sur le problème. Mais éffectivement on pourrait imaginer quelque chose de semblable

C'est dans ce DAC que tu à fait ton DataReader : http://blog.developpez.com/index.php...&c=1&tb=1&pb=1 ?

oui
Demain j'y parlerais peut-être un peu de dataAdapter si j'arrive à résoudre quelques soucis

Ca vaudrait le coup de faire pareille sur des DataRow?

Je n'utilise que des datasets fortement typés ça serait interessant à regarder mais ça ne correspond pas à mes besoins prioritaires. Et pour faire un DAC complet il y a beaucoup de points à étudier. Pour faire pareil avec un datarow, ça veut dire qu'il faudrait faire une classe qui encapsule un datset, un peu lourd quand on sait que VS.NET génère les dataset fortement typés avec un simple drag & drop

[Pete]

Ben j'attends avec impatiance la suite de ton blog !

[bisounux]

J'ai un problème dans la partie 4.3 du tuto de R.Chapuis. Lorsqu'il frabrique le DataProviderFactory, dans le switch, il instancie des classes abstraites. Est-ce une erreur ?

[Aïssa]

Bonjour,

En fait il s'est trompé les DataProvider (DataProviderSqlClient, DataProviderOleDb)ne sont pas des classes abstraites mais bien des classes concrètes, ils constituent si on veut parler en terme DESIGN PATTERN, les classes concretes qui implémentent l'interface de la fabrique Abstraite.
Je rappelle que la fabrique abstraite est une interface pour la création de familles d'objets , ce qui est le cas ici, en effet chaque Provider implement plusieurs objets ( SqlConnection, SqlAdapter...).

En revanche moi ce que je voudrai bien comprendre c'est pourquoi il a ajouté une couche d'abstraction, est ce juste pour faire joli, ou il y a une subtilité que je ne vois pas??? ;-)

Pourquoi utilise-t'il l'interface IDbProvider et la classe abstraite DataProvider, moi je n'aurai utiliser qu'une couche...

[bisounux]

Je ne sais pas pourquoi il utilise cette interface et la classe abstraite en plus. Désolé.
Merci de ta réponse.

[Aïssa]

On est obligé d'utilisé une interface ou une classe abstraite pour rendre au client une abstraction, ça je peux le comprendre, mais j'ai l'impression qu'il a un peu compliqué son code pour rien, à moins que j'ai raté un épisode...
Pourquoi n'a t'il pas utilisé une classe abstraite qui définit l'interface tout simplement...

Lui il a ajouté deux couches d'abstraction et appelle dans sa classe d'abstraction ses deux fabriques (factory) par une méthode chacune...

Qu'en pensez vous???

[Aïssa]

Bonjour tt le monde,
Aprés maintes reflexion et comme personne n'a daigné me répondre snif snif, j'ai entrepris de simplifier le Code du tuto de R. Chapuis, j'ai enléve une couche d'abstraction et je n'utilise qu'une interface IDataprovider j'ai enlevé la classe abstraite DataProvider, bon ça marche sans souci pour obtenir un objet de type IDbConnection, ceci dit je suis tombé sur un os!!!
En effet, je m'explique : je veux utiliser un IDbDataAdapter qui appelle une procedure stockée avec des paramètes, comment vous faites dans ce cas la??? cela devient compliqué!!! il faut transmettre les valeurs, les types des parametres...

Est ce qu'il y a qq qui a vraiment réaliser un DAC complet??? si oui est ce qu'il pourrait me donner des conseils ou un lien???

Merci de votre comprehension