Архитектура / Обслуживание / Развертывание больших приложений
Здесь, на работе, у нас есть очень большое приложение с несколькими вспомогательными приложениями. (500 + дллс)
Как разработчику очень сложно работать со всеми этими библиотеками и зависимостями. Вы создаете новый проект и добавляете 5+ библиотек, чтобы заставить работать основные компоненты системы (регистрация, аудит, безопасность, обмен сообщениями и т. Д.). Каждое новое добавляемое нами приложение мы создаем веб-проект, бизнес-уровень, уровень данных и любые другие проекты, необходимые для совместного использования объектов между тремя объектами, поэтому наш список просто продолжает расширяться.
Мой вопрос, каков наилучший способ справиться с этим? Кажется, я не могу думать, что лучше... модульный подход, кажется, хорош для повторного использования и горячих исправлений, не снимая систему для одного приложения. Но головная боль в управлении 500 dll - это кошмар.
Нужно ли каждой подсистеме 3-4 проекта, а также ссылки на другие 5 основных компонентов?
Каковы другие способы управления крупными проектами, помня об управлении / разработке и развертывании?
2 ответа
У меня очень хороший опыт работы с правилами именования во всех типах проектов (в настоящее время я работаю над 250+ проектами dll). Если вы (или кто-либо другой) выберете хорошие соглашения об именах, вы сначала увидите, что такое "это", и вы поймете, какое имя вам нужно.
Не беспокойтесь о количестве ссылок в проекте. Если вы разочарованы добавлением X ссылок каждый раз, вы можете создать макрос, который будет делать это вместо вас. Или вы можете создать шаблон VS решение / проект / элементы (файлы) с вашими особыми требованиями.
Большие проекты большие, поэтому неудивительно, если вам приходится работать с большим количеством библиотек, классов и т. Д.
Это продолжающаяся битва. В нашей системе около 100 различных проектов: в основном C#, с несколькими C++ проектами для низкоуровневых вещей. Если мы добавим новый проект на C#, мы должны добавить ссылки на полдюжины других проектов, просто чтобы получить базовую функциональность.
В своем примере вы говорите, что для каждого субприложения вы создаете три или более проектов (веб-проект, бизнес-уровень, уровень данных и т. Д.). Хотя мы создаем эти слои, мы стараемся, насколько это возможно, держать их в одном проекте, особенно чтобы избежать добавления ненужных проектов. Мы не будем разбивать вложенное приложение на разные проекты, если только оно не будет распределено по нескольким процессам или если мы знаем, что другим частям всей системы необходимо будет взаимодействовать с этой подсистемой.
Вполне вероятно, что каждая подсистема действительно должна ссылаться на основные части. Потребность в 3-4 проектах зависит от того, как вы его спроектировали. Мы обнаружили, что ограничение создания новых проектов частями, которые взаимодействуют с другими проектами или используются несколькими подсистемами, значительно сократило число проектов, с которыми нам приходится сталкиваться.