Почему у меня не должно быть единственной монолитной служебной библиотеки?

Я согласен с тем, что наличие единой библиотеки для этих утилит является идеальным вариантом, если пространства имен поддерживаются должным образом, а сам код хорошо разбит на части для любого будущего обслуживания библиотеки. Основное оправдание, которое я вижу для этого, - это именно то, что вы упомянули, почти все ваши внутренние приложения используют его.

Однако одна вещь, о которой следует подумать, - это функциональность этих частей. Если одна часть - это пространство имен утилит для выполнения хитроумных трюков с элементами управления или метками, а вторая часть - это библиотека безопасности, которая обрабатывает ваши процедуры входа в систему, вы можете столкнуться с некоторыми непредвиденными проблемами, когда в библиотеку утилит будет добавлен «крутой трюк D», но нарушает работу существующего приложения, которое зависит от библиотеки безопасности, но вынуждено обновляться, поскольку теперь обновлена ​​вся DLL.

Может быть причина иметь отдельные проекты для библиотек с совершенно разными целями или проекты, которые ссылаются на сторонние библиотеки. Помимо этого, вы можете поместить большинство из них в общую базовую библиотеку.

У нас есть общая библиотека для множества классов, но отдельный проект для классов, связанных с Интернетом, отдельный проект для классов, связанных с PDF (поскольку он использует сторонние DLL, который нам не нужен во всех приложениях), отдельный проект для классов, связанных с MySQL (поскольку он использует сторонний соединитель).

У нас также есть отдельный проект для классов, связанных с базой данных (MS SQL), но это может действительно вошли в общую библиотеку, поскольку у нас очень мало приложений, не использующих базу данных.

Просто поделитесь недавним опытом, который заставил меня немного изменить точку зрения на это ...

Сокращение 150 проектов в решении примерно до 30 сократило время сборки примерно на 25% от того, что было (1 минута и изменение против 5 минут на нашей типичной машине разработчика). Если вы делаете ссылки на dll, это не имеет большого значения, но если вы включаете проекты в основное решение, это может оказаться важным. Честно говоря, я был немного удивлен этой разницей, но прошлые результаты не гарантируют возврата в будущем.

Каждый раз, когда .net загружает dll впервые, вы берете на себя JIT-процесс и накладные расходы файлового ввода-вывода. Для приложений WinForm / WPF, где пользователь может запускать его несколько раз в день, это более серьезная проблема, чем веб-приложения. Даже для приложений Winform / WPF это может не вызывать большого беспокойства для многих приложений.

Еще одна вещь, на которую следует обратить внимание, - это сложные зависимости, которые вызывают ситуации, когда «если я использую A, я должен использовать B, потому что A предоставляет типы из B. Между тем, я редко использую B сам по себе» Просто объедините его и будьте покончено с этим.

Итак, я понимаю, что есть несколько конкретных причин, чтобы попытаться объединиться. Вероятно, существует миллион субъективных причин, но в большом файле решения, кажется, лучше попытаться быть простым, насколько это возможно.

Более субъективно, я бы также посоветовал вам взглянуть на файл проекта как на сборку артефакт, а не артефакт кода. Думайте о файле .cs как о том, что вы действительно хотите повторно использовать, а не о .csproj. Конечно, в большинстве случаев вы также будете повторно использовать .csproj и все время строить сборку одинаково. Но не надопроект @. Связь между .csproj и .cs в большинстве случаев достаточно слабая.

РЕДАКТИРОВАТЬ: @ - добавлено «в вашем проекте»

Я бы сказал, что все сводится к тому, что лучше всего работает для тебя. Большую утилитарную библиотеку может быть трудно найти, но опять же, все это в одном месте, где каждый знает, где искать, они могут быть более полезны. Также, в зависимости от того, как библиотека управляется, различным группам может быть проще поддерживать свои собственные библиотеки util (если им нужно контролировать изменения в них), но если она управляется одной группой (или если все ладят), то одна большая может быть проще. Так что на самом деле, что бы ни работало для вас.

Это классическая проблема "Златовласка и 3 медведя".

Вы не хотите ни одной монолитной библиотеки - и не хотите слишком много библиотек. Вы хотите точно нужное количество библиотек :) Не слишком много, не слишком мало, просто правильно.

Есть причины иметь разные библиотеки:

1) Независимость разработки - библиотеки могут разрабатываться независимо. 2) Маленькая развертываемая

Я думаю, что общим правилом может быть то, что если есть отдельная команда, которая занимается полной разработкой на определенном участке библиотеки, то она должна быть отдельной. Если несколько команд время от времени добавляют несколько битов кода, то не должно быть никаких проблем с независимостью разработки и развертывания, а также с тем же успехом можно иметь одну общую библиотеку. Звучит так, как будто это происходит в вашей ситуации, так что идите с одной библиотекой.

Другой вопрос, который стоит задать: "Какая проблема, с которой мы сейчас сталкиваемся, могла бы решить разделение библиотеки?". Если это не решает никаких проблем, то нет необходимости в отдельных библиотеках.

Точка зрения 1
Наличие как можно меньшего количества библиотек упрощает сборку сценариев и развертывание (меньше частей, о которых стоит беспокоиться). Наличие одной библиотеки со всеми внутренне разработанными компонентами пользовательского интерфейса отлично подходит для запуска новых проектов. Просто добавьте одну ссылку, и все внутренние компоненты будут готовы. Надеюсь, это уменьшит время, затрачиваемое на переосмысление компонентов, потому что кто-то забыл, что библиотека с таким компонентом уже есть. То же самое с общей библиотекой утилит - приятнее иметь только одну, так что вы получаете всю функциональность, доступную по одной ссылке.

View Point 2
Разделение различных взаимосвязанных битов функциональности на отдельные библиотеки позволяет этим библиотекам сосредоточиться и дает четкое представление об их намерениях. Так как каждая библиотека более сфокусирована, каждая отдельная библиотека будет меньше. Таким образом, ваш конечный установочный пакет может быть меньше, так как вы будете включать только те библиотеки, которые вам действительно нужны. Однако затем вам нужно будет запомнить, сколько библиотек у вас есть и что каждая из них содержит. Это может быть кошмар передачи документации и знаний.

Так что же для вас важнее, размер установки или удобство для разработчиков? Выберите приоритет, а затем подберите ему организацию кода.