Architecture/Maintenance/Déploiement de grandes applications

Question

Ici, au travail, nous avons une très grande application avec plusieurs sous-applications. (500 + dlls)

En tant que développeur, il est très frustrant de travailler avec toutes ces DLL et dépendances. Vous créez un nouveau projet et ajoutez 5+ dlls pour faire fonctionner les éléments de base du système (Logging, Audit, sécurité, messagerie ect). Chaque nouvelle sous-application que nous ajoutons, nous faisons un projet web, une couche de gestion, une couche de données et tous les autres projets nécessaires pour partager des objets entre les 3, de sorte que notre liste ne cesse de s'étendre.

Ma question est quelle est la meilleure façon de gérer cela? Je ne peux pas sembler penser ce qui est le meilleur. L'approche modulaire semble bonne pour la réutilisation, et les éléments de correction à chaud sans pour autant détruire le système pour une application. Mais le mal de tête dans la gestion de 500 dll est un cauchemar.

Chaque sous-système a-t-il vraiment besoin de 3-4 projets et de faire référence aux 5 autres composants principaux? Quels sont les autres moyens de gérer les grands projets en gardant à l'esprit la gestion, le développement et le déploiement?

Answer 1

J'ai une très bonne expérience avec les directives de nommage dans tous les types de projets (actuellement je travaille sur le projet 250 + dlls). Si vous (ou quelqu'un d'autre) choisissez de bonnes conventions de nommage, vous voyez au premier coup d'oeil ce que c'est et vous savez comment nommer est quelque chose dont vous avez besoin.

Ne vous inquiétez pas du nombre de références dans le projet. Si vous êtes frustré d'ajouter des références X à chaque fois, vous pouvez créer une macro qui vous le fera à la place. Ou vous pouvez créer un modèle VS solution/projet/éléments (fichiers) avec vos besoins particuliers.

Les grands projets sont grandes, il est donc pas surpris, si vous devez travailler avec une grande quantité de dll, classes, etc ...

Answer 2

C'est un combat permanent. Notre système compte environ 100 projets différents: principalement du C#, avec quelques projets C++ pour des tâches de bas niveau. Si nous ajoutons un nouveau projet C#, nous devons ajouter des références à une demi-douzaine d'autres projets, juste pour obtenir la fonctionnalité de base. Dans votre exemple, vous indiquez que pour chaque sous-application, vous effectuez trois projets ou plus (projet Web, couche de gestion, couche de données, etc.). Bien que nous ayons créé ces couches, nous essayons autant que possible de les conserver dans la sous-application. même projet, notamment pour éviter d'ajouter des projets inutiles. Nous ne diviserons pas une sous-application en différents projets à moins qu'elle ne soit répartie sur plusieurs processus, ou si nous savons que d'autres parties du système global devront communiquer avec ce sous-système.

Il est probable que chaque sous-système ait vraiment besoin de référencer les pièces centrales. Qu'il ait besoin de 3-4 projets ou non dépend de la façon dont vous l'avez conçu. Nous avons constaté que limiter la création de nouveaux projets à des éléments qui communiquent avec d'autres projets ou sont utilisés par plusieurs sous-systèmes a considérablement réduit le nombre de projets auxquels nous devons faire face.