Quelle devrait être la granularité des modules dans Prism?

Question

Je travaille actuellement sur un de mes projets utilisant Prism (Composite Application Library/Guidance). L'application sera une application MSPaint-like spécialisée pour le basketball (objets prédéfinis pour les balles, les joueurs etc.).

Maintenant, je me demande comment organiser mon application en modules Prism. Surtout quand on pense à la partie dessin du logiciel. Dois-je scinder la vue générale du dessin (2 colonnes: boîte à outils, canevas) en 2 modules (boîte à outils et canevas) ou la surcharge créée par la communication constante de ces modules serait-elle trop écrasante?

À quel point les modules Prism devraient-ils être à grains fins?

Merci à l'avance et meilleures salutations, crischu

Answer 1

Il y a très peu de frais généraux lorsque vous vous séparez en modules.

Je voudrais aller avec ce qui vous aide à organiser votre solution, plutôt que de se soucier beaucoup de considérations de performance. Vous pouvez facilement combiner des modules si vous trouvez qu'ils vous causent des problèmes ou si vous trouvez que deux modules appartiennent vraiment ensemble. La règle est la suivante:

Exécutez-le. Faites-le tourner à droite. Faites-le courir vite.

Dans cet ordre. Faites ce qui est bon en premier et refactorisez plus tard si nécessaire.

Answer 2

Je dirais que cela dépend de la façon dont vous distribuez la fonctionnalité de votre application sur l'interface utilisateur. Si vous n'avez qu'un seul écran, mais avec plusieurs sections qui gèrent différentes fonctionnalités, chacune de ces sections (page à onglet, panneau, etc.) devrait avoir son propre module. C'est le cas des échantillons StockTrader RI ou NewsAggregator. Mais sur le projet que nous commençons, nous avons décidé d'avoir plusieurs pages, une page pour chaque fonctionnalité majeure et d'avoir la navigation entre eux. Dans ce cas, un module représentera une page, rien de plus petit que cela.