Discussion :

[saad.hessane]

Bonjours tout le monde.
Après quelques projets en .NET (VB et C#), je me demande quelle est la meilleur façon de consulter une base de données. Que ce soit à la fois d'un point de vue architecture ou technologie.
Alors voilà j'ai des tonnes de questions que je me pose à chaque fois que je veux commencer un projet, j'espère y trouver réponse auprès de vous.
D'abord est ce que vous créez votre connexion avec l'assistant, ou par code? Je trouve l'assistant très rigide : une fois qu'on veut changer la chaine de connexion il faut le faire à grand coup de chercher remplacer.
Puis une autre question, comment faire pour passer la connexion "efficacement" entre les différents Form? Normalement j'envoie le DataSet et le TableAdapter par référence au constructeur de la Form. Est-ce la bonne méthode?
Voilà déjà ces deux questions, j'en ai encore quelques une, mais je pense que vous y répondriez indirectement.
Merci à vous.

[Graffito]

D'abord est ce que vous créez votre connexion avec l'assistant, ou par code? Je trouve l'assistant très rigide : une fois qu'on veut changer la chaine de connexion il faut le faire à grand coup de chercher remplacer.

Par code, avec une bibliothèque dédiée qui s'adapte de façon transparente à plusieurs SGBD différents (Access, MySql, Oracle).

comment faire pour passer la connexion "efficacement" entre les différents Form? Normalement j'envoie le DataSet et le TableAdapter par référence au constructeur de la Form. Est-ce la bonne méthode?

Je définis pour chaque table l'instance d'une classe dédiée "TableDeSgbd" qui comporte principalement le nom de Table, la DataTable, le DataAdapterle et le DataSet.
Ensuite, je la passe aux forms :

• soit directement par une méthode de la form,
• soit via un objet applicatif accessible par toutes les forms et qui contient toutes les instances de "TableDeSgbd",
• soit via une fonction de bibliothèque qui permet d'enregistrer un objet dans un "dictionnaire" (nom,objet) de variables globales et de retrouver un objet global par son nom (reste plus qu'à faire un cast en TableDeSgbd sur l'objet retourné).

[tomlev]

Pour ce qui est des bonnes pratiques, regarde cet article

D'abord est ce que vous créez votre connexion avec l'assistant, ou par code?

Tu parles de quel assistant ? le designer de DataSet ? Pour créer les tables, c'est assez pratique. Par contre, j'évite comme la peste les TableAdapters, qui sont terriblement rigides et mal conçus. Quand je travaille avec des DataSets, je préfère créer moi-même mes DataAdapters, qui permettent de spécifier moi-même la connexion à utiliser. Si tu veux écrire du code indépendant de type de SGBD, les TableAdapters sont complètement inadaptés, car ils codent en dur les types concrets à utiliser (OracleConnection, SqlConnection, etc...), au lieu d'utiliser la couche d'abstraction (DbConnection, DbDataAdapter, etc)

une fois qu'on veut changer la chaine de connexion il faut le faire à grand coup de chercher remplacer.

Chercher remplacer ?! La chaine de connexion est définie à un seul endroit, dans le fichier Settings.settings...

Puis une autre question, comment faire pour passer la connexion "efficacement" entre les différents Form? Normalement j'envoie le DataSet et le TableAdapter par référence au constructeur de la Form. Est-ce la bonne méthode?

C'est une bonne méthode, mais il y en a d'autres... par exemple, tu pourrais utiliser un singleton qui expose la connexion, passer par une propriété, ou utiliser l'injection de dépendence...

[cinemania]

Puisque dans ta question il y avait méthodes et technologies... je vais donc rejouer mon rôle favori... apôtre des nouvelles technologies...

Tout d'abord pour la connexion en général on passe par des Factory dans une lib indépendante prévue pour qui va te permettre de générer de façon transparente la bonne connexion SQL en fonction du type de base que tu souhaite ralier, ensuite, il y a donc toute cette notion de provider fourni généralement par les connecteurs tiers pour des bases non prises en charges par .NET de façon native.

Ensuite pour ce qui est de la technologie... Il est assez dommage, surtout maintenant, de ce cantonner à DotNet 2.0
tu a demandé en terme de technologies et sous prétexte que tes exemples parlaient de dotnet2.0 mes confrères se sont cantonné à te répondre sur ce modèle...
Actuellement on est à l'ère de Visual Studio 2010, de Dotnet 4 et donc ADO.NET 4 aussi et si on regarde les technologies fournies par ADO.NET, on a donc les bonnes vieilles méthodes, avec DataSet, DataTable ...
Puis on a Linq To SQL (>= dotnet 3.0), que je déconseillerai même si c'est un très bon préambule à Entity Framework.
Puis pour finir Entity Framework 1 (dotnet 3.5SP1)
et Entity Framework 2 (dotnet 4)

Actuellement Microsoft conseil, et pousse à utiliser Entity Framework pour des raisons évidentes. EF fourni le provider linq, Linq to Entities permettant d'utiliser l'écriture Linq to Object, Linq to SQL appliquée à Entity Data Model.

Pourquoi une technologie plus que l'autre ?
Et bien je dirai qu'il faut choisir la technologie en fonction des besoins.

Si ton besoin est d'ordre consultatif uniquement et que le type de données manipulé est inconnus, ne correspond pas à une logique métier, ADO.NET 2 est parfait avec les DataSet et DataTable.

Dès lors que tu commence à avoir des objets métiers, et que tu dois te triturer les neuronnes pour passer du DataSet aux collections d'objets métier, obligeant ainsi à créer des classes pour gérer la logique d'accès aux données pour ces objets métiers, je dirais qu'il ne faut plus partir vers ADO.NET 2 mais s'orienter vers 3.5SP1 ou 4, et tout particulièrement Entity Framework.
(Tu peux toujours aussi avoir recours à des framework tiers, reconnus, comme NHibernate)

L'intérêt est que tu va concevoir ton modèle objet soit en partant de ton modèle relationnel s'il est déjà là, genre car tu reprend un applicatif vieillissant, soit directement sans te soucier de la représentation et de la persistance, puis depuis ce modèle tu va demander à l'outil de visual studio pour EF2 de générer la base de données qui va bien en accord avec ton modèle objet, et qui va au passage concevoir tout le mapping entre la base de données, et tes objets.
En fait Entity Framework est là pour permettre de faire cette corrélation, ce mapping entre monde Objet, donc ton programme, et le monde relationnel, la base de données, qui ne sont pas forcément identiques. N'oublions pas qu'il arrive qu'une base de données dispose de tables qui n'ont pas lieu d'être dans un modèle objet bien conçut...

Cela dit, développer avec Entity Framework ne t'abstiens pas de toujours avoir une librairie pour gérer de façon transparente la connexion à diverses bases fournissant aussi les connecteurs (qui doivent supporter entity framework)

Pour ce qui est de la chaine de connexion, tout le monde ne développe pas en Visual Basic, aussi je ne vois pas pourquoi elle serait spécifiquement dans Settings.Settings, qui n'est qu'un raccourci des projets VB.

Typiquement, une chaine de connexion doit être dans le fichier d'app.config de l''application et pourquoi pas dans la section ConnectionString histoire de laisser ADO.NET la trouver tout seul comme un grand... surtout quand tu travail avec Entity Framework, plutot que dans la section des userdefined histoire de devoir te débrouiller toi même...
en général les connections string surtout pour entity framework possèdent des informations comme le provider, et l'assembly du provider nécessaire pour le fonctionnement sur un sgbd donné.

Pour ce qui est du passage de la connexion ?
Quand je développe une lib pour y mettre toute la modélisation objet et toute la gestion logique des données qui va avec, j'y met également un manager en singleton qui expose et gère une instance de l'objet de contexte fortement typé de l'Entity Data Model, ce qui me permet de le retrouver partout, et donc d'avoir une instance unique de chaque objet correspondant bien à une entrée donnée dans la DB et pas 36 objets reflétant la même entrée dans la DB.
Si je développe pour un modèle n-tiers je préconise de ne pas mettre ce manager dans la même lib que les modèles objets.

[saad.hessane]

Merci à vous tous, vous m'aidez vraiment.