Comment organisez-vous des cours sur un grand projet?

Question

Nous avons une tonne de fonctionnalités dans notre application qui peuvent être décrites très concrètement comme un module. Ils ont généralement une sorte de boîte de dialogue d'installation, puis lorsque l'utilisateur clique sur OK, il configure un processus à exécuter et exécute ce processus. Parfois, ils sont plus impliqués et l'utilisateur va ouvrir la nouvelle boîte de dialogue et travailler sur la boîte de dialogue pendant un certain temps, faisant beaucoup de choses qui apportent des modifications à la base de données sous-jacente.

je finis généralement avec plusieurs classes standard

ConfigPanel.cs 
ConfigPanelData.cs 
ProcessRunner.cs 
ApiWrapper.cs (for calling the process from somewhere else) 

Si j'avais un plus bout en bout module, il est peut-être WorkerPanel.cs WorkerData.cs SetupOptions.cs (état du panneau a persisté entre les courses) Lib/WhateverBackendStuffINeedToSupportModule ApiWrapper

En ce moment, il y a des dossiers pour chacun:

UI/Panels/ 
    Module1Panel.cs 
    Module2Panel.cs 
UI/PanelData/ 
    Module1PanelData.cs 
    Module2PanelData.cs 
UI/PanelManagers 
    Module1PanelManager.cs 
    Module2PanelManager.cs 
Core/Module1/ 
    Module1.cs 
    Module1Helpers.cs 
Core/Module2/ 
    Module2.cs 
    Module2Helpers.cs 

Comme vous pouvez le voir, tout est vraiment étalé. Avec plus de 50 modules, ces dossiers ne sont pas vraiment organisés. Même en les cassant par sous-système, ils sont encore en désordre. Serait-ce une mauvaise conception que de tout mettre ensemble pour que tout soit séparé par fonction plutôt que par type de classe?

Module1/ 
    Module1Panel.cs 
    Module1PanelData.cs 
    Module1PanelManager.cs 
    Module1PanelLib.cs 
    Module1PanelWrapper.cs 
Module2/ 
    Module2Panel.cs 
    Module2PanelData.cs 
    Module2PanelManager.cs 
    Module2PanelLib.cs 
    Module2PanelWrapper.cs 

Comment organisez-vous vos cours et quels sont les avantages/inconvénients?

Answer 1

Serait-il une mauvaise conception juste mettre tout ensemble, donc tout est séparés par fonction plutôt que type de classe?

Il n'y a pas de règle générale, cela dépend de la situation, de vos préférences personnelles et des changements de modèles dans votre code. Cependant, je vous conseille de faire ce qui suit:

• Gardez autant de code commun dans les superclasses pour éliminer toute redondance. Peut-être que certaines des sous-classes ne seront même pas nécessaires. Je ne suis pas sûr de ce que vous entendez par "modules", mais je vous recommande de séparer le contenu en utilisant les namespaces + sous-répertoires dans le même projet et non en utilisant des assemblages séparés. Utilisez des assemblys uniquement à des fins de séparation de déploiement et autres.
• Ces classes "d'aide" que vous mentionnez sonnent un peu malodorantes. Ils pourraient être une violation des principes OO. Consultez ce lien pour plus d'informations: http://blogs.msdn.com/nickmalik/archive/2005/09/06/461404.aspx. Peut-être que vous pouvez réorganiser le code, réduire le besoin de ces classes et bénéficier d'un design OO plus propre en même temps?