Silverlight - Modularité. La meilleure façon de séparer physiquement les binaires?

Question

Nous travaillons sur l'application LOB avec beaucoup de contenu. Le téléchargement XAP sera assez grand, je pense que pour une fois le téléchargement. Je prévois de diviser la solution en projets séparés.

Je ne sais pas pourquoi - mais je n'aime pas beaucoup de projets en solution. OMI ce n'est pas une très bonne idée. Même lorsque nous travaillions comme une grande équipe - c'était une douleur avec de nombreux projets.

Même maintenant, quand j'utilise MEF / Prism - il y aura encore des dépendances de base comme:

1. Bibliothèques de prisme
2. Interfaces
3. La navigation
4. Shell / bootstrapper
5. Styles d'application
6. Convertisseurs / commandes / validateurs
7. etc.

Et que je vais avoir des modules qui utiliseront toutes ces choses de base. Les modules auront des suites:

1. Côté client des services RIA
2. ViewModel
3. Vues

Ces modules seront chargés à la demande à l'aide de MEF. Je pense que sur la taille, tous ces modules seront plus grands que le module de base en raison de la logique de la logique.

Je m'attends à avoir environ 5-6 modules et noyau. Je pense que cela me donnera un nombre raisonnable de projets et de bibliothèques côté client / XAPS et ce sera une solution gérable avec laquelle travailler.

Voyez-vous un problème avec une rupture comme celle-ci? Certaines vidéos en ligne feront plus de 7 projets à partir du module de base. Qu'est-ce qu'un point? Je pense que cela ajoute à la complexité. Qu'ils montrent 3-4 DLL hors du module. Un pour les vues, un pour ViewModels et ainsi de suite. Ils doivent encore être chargés ensemble, alors pourquoi?

Je cherche à faire et à ne pas être de vous les gars qui ont traversé ça.

Merci!