GUI, BLL, DAL Organisation dans un projet

9

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

c# code-organization layers sooprise
la source

Réponses:

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

Matthew Rodatus
la source
Donc, businessObject.PerformOperation () ressemblerait à quelque chose comme: DataAccessObject.PerformOperation (), car une instance de DataAccessObject vit dans businessObject?
sooprise
1
Merci aussi pour le conseil sur l'injection de dépendance. C'est un nouveau concept pour moi, et cela semble logique. Je vais devoir en savoir plus à ce sujet :)
sooprise
@sooprise Right - vos objets métier doivent fonctionner sur les objets d'accès aux données qui vivent en tant que membres privés. Heureux que vous appréciez le conseil sur l'injection de dépendance. C'est un concept crucial pour la conception de logiciels maintenables et testables. De rien!
Matthew Rodatus
2

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

Wolfgangsz
la source
Vous avez raison de dire que la conception spécifique est dictée par les besoins de l'application. Cependant, à moins que je ne comprenne mal votre conception, je ne suis pas d'accord sur l'utilisation de singletons. Peut-être pourriez-vous expliquer davantage votre approche. Pourquoi les singletons sont mauvais: blogs.msdn.com/b/scottdensmore/archive/2004/05/25/140827.aspx
Matthew Rodatus
Je suis désolé, mais je ne suis pas d'accord sur les singletons. Il y a de très bonnes raisons de les utiliser, et toutes les choses mentionnées dans ce blog ressemblent à des excuses de quelqu'un qui ne veut pas appliquer la discipline nécessaire à son codage.
wolfgangsz
Une explication détaillée de mon approche remplirait beaucoup plus que ce que je peux fournir ici dans les commentaires. Envoyez-moi votre adresse e-mail et je vous répondrai (wolfgangs at manticoreit dot com)
wolfgangsz