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

Question

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

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

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

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

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

Answer 1

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

Не обязательно.Обычно это заканчивается именно так, потому что мои библиотеки обычно не очень большие, но вы заметите, что Microsoft определенно этого не делает.Система.Веб существует, даже если вы не включаете систему.Ссылка на веб-сайт.Ты просто получишь больше уроков, если сделаешь это.Указывает, что пространство имен 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

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

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

Answer 4

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

Я думаю, что общее правило может быть таким:если проект действительно можно разработать независимо от всех остальных и подключить к другим проектам без каких-либо других зависимостей, тогда сделайте его отдельным проектом.Если вы обнаружите, что всегда есть другие проекты, на которые необходимо ссылаться, чтобы он работал (например, возможно, в вашем проекте «Мониторы» вы обнаружите, что вообще ничего не будет работать, если вы также не включите пространство имен «Компьютеры» в классы графического процессора), тогда я бы объединил их в один проект.

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

Просто мои два цента, они не многого стоят...

Answer 5

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

Answer 6

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

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