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

Question

У нас есть несколько общих библиотек (C #, но я думаю, это не зависит от платформы или языка), давайте назовем их A, B и C. Библиотека A имеет ссылки на B и C, библиотека B имеет ссылка на стороннюю DLL, и библиотека C стоит отдельно. Идея трех отдельных проектов заключалась в том, что каждая библиотека имела различные функциональные возможности, но со временем библиотека A стала более или менее универсальной общей библиотекой, на которую ссылается большинство клиентских приложений. Только несколько приложений ссылаются на B и / или C без A.

Мы пытаемся улучшить наши соглашения об управлении исходным кодом, и мы пытаемся правильно пометить и освободить эти библиотеки DLL, чтобы файлы клиентских проектов могли указывать на статическую версию кода вместо всегда смена багажника. Это оказывается немного запутанным - например, клиентский проект, который ссылается на A и B. Сам A ссылается на B, так что технически есть две ссылки на B, исходящие из клиентского проекта.

Таким образом, очевидно, что нужно просто объединить все в одну общую / служебную библиотеку с хорошо организованными пространствами имен. Как я уже сказал, почти каждое клиентское приложение ссылается на одну из этих библиотек, так кого это волнует? Это не приведет к нежелательным ситуациям со сторонними зависимостями, и все наши целевые машины являются внутренними и поддерживают примерно одинаковую конфигурацию среды / программного обеспечения.

Это кажется слишком простым решением, поэтому я решил, что по крайней мере получу второе мнение. Альтернативой может быть использование GAC и строгая подпись / версия всего. Я что-то здесь не ловлю?

Answer 1

Я думаю, вы объединяетесь в одну библиотеку.

Очень часто код разбит на слишком много развертываемых модулей, тогда как логическая часть функциональности кажется критерием разделения. Это неверно ИМО. Сборки должны быть согласованы со сценариями развертывания и циклами выпуска. В противном случае вы получите ужасно сложный граф зависимостей, где в любом случае каждая сборка управляется, собирается и разворачивается вместе.

Интересный вопрос, хотя! Давайте посмотрим, что думают другие люди:)

Answer 2

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

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

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

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

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

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

Answer 3

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

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

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

Answer 4

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

Answer 5

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

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

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

Answer 6

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

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

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

Answer 7

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

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

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

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

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

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

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