Architecture de couche de présentation dans une application d'entreprise

Question

Dans notre société, nous développons une application composée de plusieurs modules. L'architecture est assez bien définie mais j'ai quelques secondes à propos de la couche de présentation et j'aimerais vraiment entendre vos opinions. L'architecture est la suivante:

Foreach module nous créons plusieurs espaces de noms et ceux-ci seront compilés dans leur propre bibliothèque de classes. Donc, pour notre module CRM nous créons les éléments suivants:

• ProductName.CRM.ServiceLayer (contient les interfaces servicecontracts du module CRM)
• de ProductName.CRM.ServiceLayer.Implementation (implémente les interfaces servicelayer du module CRM)
• ProductName.CRM.BusinessLayer (détient les businesscomponents du module CRM)
• ProductName.CRM.BusinessLayer.BusinessObjects (détient le businessobjects du module CRM)
• ProductName.CRM.DataLayer (détient les interfaces DAO du module CRM)
• ProductName.CRM.DataLayer.SqlServer (implémente les interfaces du module CRM dataLayer)

Nous créons la même structure des bibliothèques de classes pour les modules Finance, gestion des ressources humaines, approvisionnement, etc:

• ProductName.Finance ....
• ProductName.HRM ....
• etc. Je pense que vous avez l'idée pour l'instant :)

Nous avons aussi pensé aux « préoccupations qui transcendent » et que nous créons les espaces de noms suivants et les bibliothèques de classes

• de ProductName.Framework.ExceptionHandling
• de ProductName.Framework.Logging
• ProductName.Framework.Security
• etcetra ...

voilà donc comment notre architecture est à ce jour et en ce moment je suis en train de trouver un prope r moyen de configurer PresentationLayer. Par exemple, devrais-je créer une bibliothèque PresentationLayer pour chaque module (ProductName.CRM.PresentationLayer, ProductName.Finance.PresentationLayer, etc.). Et créez une bibliothèque ProductName.PresentationLayer globale qui a des références à toutes les autres bibliothèques Module.PresentationLayer. Ce ProductName.PresentationLayer global aura alors la fonctionnalité Login/MainForm et la possibilité de démarrer des formulaires implémentés dans l'un des modules PresentationLayer. Ce sera comme un point d'entrée de l'application pour d'autres modules.

Ou ...

Dois-je faire un seul ProductName.Presentation-bibliothèque qui contient toutes les formes pour tous les modules. En faisant cela, je peux naviguer facilement vers d'autres formulaires et je n'ai pas à m'inquiéter des références entre les modules quand ils vont utiliser les autres formulaires (parfois ils le feront).

Les premières solutions me semblent bonnes. Cependant, lorsque les formulaires de différents modules veulent naviguer les uns aux autres.Ce type de fonctionnalité sera difficile à mettre en œuvre car seul l'un des deux peut avoir la référence à l'autre. Je voudrais vraiment entendre vos opinions sur ce problème et peut-être que quelqu'un pourrait me donner une bonne solution ou une idée que je peux utiliser.

merci d'avance, Cheers!

Answer 1

Vous pouvez toujours créer des interfaces qui forment des implémentations si elles doivent échanger des données. En fait, ce n'est probablement pas une bonne idée d'avoir beaucoup de formulaires se connaissant les uns les autres car cela crée des problèmes de maintenance et d'amélioration à long terme. En utilisant des interfaces et potentiellement un type de service de localisation, vous pouvez éviter les dépendances entre les formulaires. Vous pouvez ensuite utiliser l'un ou l'autre modèle d'architecture (1 grand assemblage par rapport à de nombreux plus petits).