conseils sur la séparation des projets dans .NET

Question

Je cherche des conseils sur la séparation des projets .NET. Je construis une grande application Windows (80 tables) et j'ai seulement quelques projets. Ils deviennent assez gros. J'ai remarqué le problème quand j'ai vu la liste des références l'autre jour. C'est la première fois que je crée une application aussi grande, donc la désignation des projets et leur séparation deviennent un peu confuses.

Voici ce que j'ai, et les préoccupations de chaque projet.

ProjectName.Dal (accès aux données, cela est généré automatiquement pour moi, je ne touche pas.)

ProjectName.Bll (référentiels, communiquer avec les services Web, générant des e-mails, générer des documents Excel et Word)

ProjectName.Model (objets de domaine)

ProjectName.UI (Windows Forms et les contrôles utilisateur)

ProjectName.UI.Web (certaines pages Web pour une petite interface web pour le système)

ProjectName.UI.Controls (fenêtres génériques personnalisées constituent des contrôles)

ProjectName.UI.Presenters (un couple de présentateurs pour les formes MVP)

ProjectName.Reminder (un service Web pour l'application qui rappelle les gens à faire des choses)

ProjectName.Tests (poignée tous les tests unitaires) - Je ne suis pas sûr que chaque projet doit avoir un projet de tests, par exemple ProjectName.UI.Presenters.Tests

Answer 1

Une chose que j'aime à se séparer comme un ensemble séparé de ceux que vous avez déjà mentionné est un projet « proxy ».

Supposons que vous consommez un de vos webservices dans votre niveau de présentation. Au lieu de référencer directement le service (wcf/.asmx) dans le niveau de présentation, j'aime avoir un projet distinct dédié à l'encapsulation du proxy à ce service. J'ai généralement une classe wrapper autour du proxy lui-même pour aider à gérer les fautes et s'assurer que le proxy est toujours disponible pour le niveau présentation (ou donner de bonnes exceptions sinon) et fournir de beaux objets de niveau présentation hors du proxy. Par exemple, je pourrais vouloir passer Widget [] au lieu d'un DataTable de widgets de mon service à mon proxy pour que tout soit sympa et SO-compatible (évidemment, nous ne voulons pas passer DataTables d'un service car ils sont tous mais il est incompréhensible au niveau .xsd) Mais les DataTables sont agréables à lier dans le niveau de présentation, donc j'enveloppe le proxy réel qui obtient ce widget [] avec un 'managedProxy' qui fait la conversion du tableau vers le DataTable ainsi que gère l'appel proxy. Cette séparation du mandataire du niveau de la présentation au niveau de la classe est ensuite poussée plus loin en l'insérant dans son propre projet. Cela le rend plus portable pour passer à la prochaine étape du moment.

Answer 2

Pour autant que je peux dire, c'est beaucoup trop séparation.

Je pense que la meilleure structure serait quelque chose comme:

• ProjectName.Dal
• ProjectName.Bll
• ProjectName.Model
• ProjectName.UI
• ProjectName.Reminder

Les tests peuvent être inclus pour chaque projet, il vise, dans un dossier/espace de nom séparé, mais qui est soumis à un autre débat. Mais sérieusement, avoir trop de projets dans une solution ralentit non seulement votre machine, mais compromet votre santé mentale pour des objets néanmoins couplés qui fonctionnent ensemble de toute façon.

Answer 3

Utilisez des dossiers dans les projets pour séparer davantage vos classes les uns des autres en fonction du domaine. En outre, vous pouvez créer des dossiers de solution dans Visual Studio. Il s'agit de dossiers virtuels pouvant être utilisés pour regrouper des projets dans votre solution. Faites un clic droit sur la solution dans l'explorateur de solution, et créez un dossier de tests, par exemple, et vous pouvez y placer des projets de test, installer des projets dans un autre, etc, etc ... Vous pouvez aussi diviser d'autres domaines .