Как вы структурируете свои повторно используемые библиотеки?

Question

Как вы организуете свой код так, чтобы его можно было легко переносить в бизнес-проекты без ненужного раздувания?

Например (в .Net), допустим, у вас есть следующие пространства имен:

namespace Computers
    - Hardware
         - Motherboard
         - GPU
namespace Monitors
    - Display
         - Mirrors
namespace Peripherals
    - USB
    - PS/2

• Вы создаете проект для родительского пространства имен и затем ссылаетесь на этот dll проекта в других проектах?
• Вы создаете одну большую библиотеку классов и переносите эту штуку (даже если вам нужно всего 5% библиотеки)?
• Или вы просто создаете один файл и копируете нужный код в этот файл; использовать этот файл во всех проектах, в которых вы нуждаетесь для создания архитектуры «включай и работай» (как бы плохо это ни казалось)?

Edit: Я не ищу ответы .Net конкретно, но это конкретный пример, который я использую (поскольку абстрактный пример затруднит понимание вопроса в данном случае)

Answer 1

Вы создаете проект для одного из родителей? пространство имен, а затем ссылка на это проект dll в других проектах?

Не обязательно. Обычно это заканчивается тем, что мои библиотеки обычно не очень большие, но вы заметите, что Microsoft, конечно, этого не делает. System.Web существует, даже если вы не включили ссылку на System.Web. Вы просто получаете больше классов, если вы делаете. Указывает на то, что пространство имен System.Web используется в нескольких разных DLL.

Вы создаете одну большую библиотеку классов и портировать эту вещь вокруг (даже если вам нужно всего 5% от библиотеки)?

Да. Место на жестком диске дешево, дешевле, чем поддержка избыточного кода.

Или вы просто создаете один файл и скопируйте нужный код в этот файл; тащит этот файл во все проекты, которые вам нужны для достижения архитектура «подключи и работай» (как плохо как это кажется)?

Это зависит от функции. Я обычно помещал что-то подобное в фрагмент кода. Например, типичная функция, которая появляется в моих веб-проектах, выглядит примерно так:

void ShowErrorMessage(HtmlTableRow row, string message)
{
   row.Cells.Clear();
   row.Cells.Add(new HtmlTableCell());
   row.Cells[0].InnerHtml = message;
   row.Cells.Attributes.Add("class", "error");
   row.Visible = true;
}

Это никогда не казалось хорошим кандидатом на библиотечную функцию, потому что тогда мне пришлось бы передать класс CSS, который я хотел использовать, и иногда значение colspan для ячейки. Но вы увидите такую ​​реализацию в нескольких местах в моих веб-проектах.

Answer 2

Я беру свою реплику с ДНК и копирую всю или часть своей огромной библиотеки классов из проекта в проект, даже если я использую только 1% библиотеки в каком-либо одном проекте. Я свободно переписываю методы и классы по мере необходимости.

Хотя этот подход несколько противоречит общепринятым знаниям в области программирования, я бы не стал его сбивать: он успешно работал для живых существ в течение последних 3,5 миллиардов лет. Как и в жизни, альтернатива (цементирование интерфейсов и реализаций путем совместного использования скомпилированных сборок между проектами) препятствует изменениям и фактически гарантирует возможное исчезновение.

Answer 3

Для вещей, которые используются в нескольких проектах, я обычно использую один большой подход к DLL. Но вот в чем проблема, если у вас много проектов, использующих этого парня, я настоятельно рекомендую назвать его строго и добавить в GAC. Когда вы будете добавлять все больше и больше проектов, вы в конечном итоге столкнетесь с желанием внести кардинальные изменения в общий компонент. Если вы не используете сильные имена / GAC, то вам придется обновлять каждое приложение, когда вы вносите изменения, и вы неизбежно забудете об этом, и что-то в работе взорвется.

Сильно назовите его, сохраняйте версию выпуска в централизованной папке в системе контроля версий и всегда ссылайтесь на нее. Затем на развертывание бросить его в GAC.

Answer 4

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

Answer 5

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

Полагаю, общее правило может быть таким: если проект действительно может быть разработан независимо от всех остальных и подключен к другим проектам без каких-либо других зависимостей, то сделайте его собственным проектом. Если вы обнаружите, что всегда есть другие проекты, на которые нужно сослаться, чтобы он работал (например, возможно, в вашем проекте Monitors вы обнаружите, что вообще ничего не будет работать, если вы не включите пространство имен Computers в классы GPU), тогда я бы собрал их в один проект.

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

Только мои два цента, не стоит много ...

Answer 6

Я сохраняю каждый компонент как отдельный модуль и использую Maven для управления своими зависимостями (это не только для Java, см. вопрос , Byldan .Net эквивалент).

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