Архитектура / Обслуживание / Развертывание больших приложений

Question

Здесь на работе у нас очень большое приложение с несколькими подприложениями. (500 + dll)

Как разработчик очень разочаровывает работа со всеми этими библиотеками и зависимостями. Вы создаете новый проект и добавляете 5+ библиотек, чтобы заставить работать основные компоненты системы (регистрация, аудит, безопасность, обмен сообщениями и т. Д.). Каждое новое добавляемое нами приложение мы создаем веб-проект, бизнес-уровень, уровень данных и любые другие проекты, необходимые для общего доступа к объектам, поэтому наш список постоянно расширяется.

Мой вопрос: каков наилучший способ справиться с этим? я не могу думать, что лучше ... модульный подход, кажется, хорош для повторного использования и горячих исправлений, не снимая систему для одного приложения. Но головная боль при управлении 500 dll - это кошмар.

Нужно ли каждой подсистеме 3-4 проекта, а также ссылки на другие 5 основных компонентов?

Каковы другие способы управления крупными проектами с учетом управления / развития и развертывания?

Answer 1

У меня очень хороший опыт работы с правилами присвоения имен во всех типах проектов (в настоящее время я работаю над проектом 250+ dll). Если вы (или кто-либо другой) выберете хорошие соглашения об именах, вы на первый взгляд увидите, что такое «это», и вы поймете, какое имя вам нужно.

Не беспокойтесь о количестве ссылок в проекте. Если вы разочарованы добавлением X ссылок каждый раз, вы можете создать макрос, который будет делать это вместо вас. Или вы можете создать шаблон VS решение / проект / элементы (файлы) с вашими особыми требованиями.

Большие проекты большие, поэтому неудивительно, если вам приходится работать с большим количеством библиотек, классов и т. Д. *

Answer 2

Это продолжающаяся битва. В нашей системе около 100 различных проектов: в основном C #, с несколькими C ++ проектами для низкоуровневых вещей. Если мы добавим новый проект C #, мы должны добавить ссылки на полдюжины других проектов, просто чтобы получить базовую функциональность.

В своем примере вы говорите, что для каждого подкласса вы создаете три или более проектов (веб-проект, бизнес-уровень, уровень данных и т. Д.). Хотя мы создаем эти слои, мы стараемся изо всех сил держать их в одном проект, специально чтобы избежать добавления ненужных проектов. Мы не будем разбивать вложенное приложение на разные проекты, если только оно не будет распределено по нескольким процессам или если мы знаем, что другим частям всей системы необходимо будет взаимодействовать с этой подсистемой.

Вполне вероятно, что каждая подсистема действительно должна ссылаться на основные части. Потребность в 3-4 проектах зависит от того, как вы его спроектировали. Мы обнаружили, что ограничение создания новых проектов частями, которые взаимодействуют с другими проектами или используются несколькими подсистемами, значительно сократило число проектов, с которыми нам приходится сталкиваться.