GUI, BLL, DAL Organisation dans un projet

Je lis sur les couches d'application et souhaite utiliser cette conception dans mon prochain projet (c #, .Net). Quelques questions:

1. La séparation des couches se fait-elle via des espaces de noms? Project.BLL.What, Project.DAL.Wthing

2. Est-il plus approprié de séparer par couches, puis composants (Project.BLL.Component1), ou par composants, puis couches (Project.Component1.BLL)

3. Pour mon DAL, cette couche est-elle davantage organisée en utilisant différentes classes? Si tous les appels de base de données sont placés dans une seule classe, il n'y a pas d'organisation. Serait-il préférable de les diviser en différentes classes ou espaces de noms?

4. Les classes DAL sont-elles généralement statiques? Il semble fastidieux d'instancier un objet DAL avant d'appeler une de ses méthodes à chaque fois.

Tout autre conseil pour faire les choses correctement avec ces couches serait apprécié.

1. Oui. Et aussi des assemblages.
2. Je me séparerais par couches, puis par composants.
3. Oui. Il existe différentes approches à cela, mais j'aurais un IDatabaseService (faisant abstraction des différentes manières d'appeler la base de données - cela peut presque être un mappage direct de ExecuteScalar / ExecuteNonQuery / ExecuteReader), puis diverses classes d'accès aux données qui partition par type de données. Par exemple, vous pourriez avoir une classe UserDataAccess qui aurait des méthodes CRUD simples qui créent / modifient / suppriment des objets User. Une autre approche serait d'avoir un objet User dans lequel le CRUD est intégré.

4. Non. Cela rend le test unitaire beaucoup plus difficile. Vous devez utiliser l' injection de dépendances pour transmettre des dépendances au constructeur de chaque classe d'accès aux données (comme un IDatabaseService). Vous devez ensuite passer les objets d'accès aux données aux objets métier, comme ceci:

   BusinessObject businessObject = new BusinessObject (new DataAccessObject (new DatabaseService ())); businessObject.PerformOperation ();

Chaque objet métier peut nécessiter plusieurs objets d'accès aux données. Votre code GUI utiliserait également un ou plusieurs objets métier. Certains objets métier peuvent ne pas avoir besoin d'objets d'accès aux données, mais ne doivent jamais utiliser directement IDatabaseService.

Pour les questions 1 et 2, allez avec les réponses de Matthew.

J'ai passé beaucoup de temps à essayer de trouver la meilleure façon de structurer le DAL des applications de bureau. Et la meilleure façon dépend vraiment des besoins de l'application. Dans l'une de mes applications, j'ai opté pour une classe DA pour chaque table de base de données, qui s'est inscrite auprès d'une classe DataProvider centrale (c'est-à-dire singleton) et a géré le CRUD. Chaque classe DA pouvait alors décider si elle voulait mettre en cache toutes les données de la table dans la RAM ou non (performances!) Et / ou si elle devait avoir la capacité de déclencher des mises à jour automatiques des clients dans d'autres clients fonctionnant sur d'autres ordinateurs (pensez multi-utilisateurs simultanéité). Cela facilite l'ajout de nouvelles classes DAL, car il leur suffit de se conformer à l'interface d'enregistrement.

Tous les DAL n'ont pas besoin de ce type de fonctionnalité, mais j'ai appris que l'approche elle-même (c.-à-d. Fournisseur de données singleton et classes DAL simples avec enregistrement statique) m'a beaucoup simplifié la vie lorsque j'ai commencé à ajouter de nouvelles classes.

Je ne recommanderais certainement pas de construire le CRUD dans des classes de niveau supérieur, sauf s'il s'agit d'une application très simple. Le DAL est une abstraction du stockage de données. Si vous décidez de changer votre stockage de données à un moment donné dans le futur (même si c'est uniquement pour utiliser MySQL au lieu de MS SQL), vous en serez très reconnaissant. Plus: les objets BLL doivent être structurés par leurs relations de logique métier. Les objets DAL sont structurés par les types de conteneurs de stockage qu'ils représentent. Les différences peuvent être dramatiques.

Ne rendez PAS vos classes DAL statiques. Ce que vous gagnez en vitesse de codage, vous le perdrez plusieurs fois en testabilité et en flexibilité.