Что положить в какую библиотеку?

Question

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

Итак, несколько примеров / вопросов для начала:

1. Два класса, IMessageBus и MessageBus, который является общим EventAggregator, который позволяет подпискуи публикация сообщений любого типа.Может быть использован любой проект.Где поставить эти классы?Как назвать библиотеку, и что еще будет принадлежать этой библиотеке?

2. Как насчет модулей методов расширения общих типов .net, вы бы поместили все это в одну библиотеку?

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

---

РЕДАКТИРОВАТЬ:

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

Answer 1

Разделять только тогда, когда вам это нужно.

Как и в случае с именами типов, переменных, файлов и т. Д .: не создавайте его, если вы не знаете, как его вызвать. Это признак незнания того, что это такое и какова его цель.

Причины для разделения: отдельное управление версиями, отдельные типы развертывания и скрытия с использованием «внутренних»

Answer 2

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

Когда я пишу клиент-серверные решения, у меня обычно будет 3 сборки,один для клиента, один для сервера и третий проект, представляющий объекты, совместно используемые обоими.И клиент, и сервер будут иметь ссылку на общий проект, но не друг на друга.

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

Answer 3

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

Группировка вещей связанным способом - это хорошее общее правило, но, не зная причины раскола, это все, что вы собираетесь получить. :)

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

Физическое разделение, вероятно, не очень поможет вам с вышесказанным. Мне кажется, что если «нахождение какой части» является реальной причиной для беспокойства, то в вашей библиотеке вы нарушаете принцип единой ответственности (SRP), вы, вероятно, также не кодируете интерфейсы или не используете модульное тестирование.

Использование пространств имен в сборке дает вам настолько большое разделение, насколько вам необходимо в отношении организации. По моему мнению, причина разбивать вещи на библиотеки классов в первую очередь для того, чтобы делиться, исправлять и скрывать вещи (через внутреннее пространство), которые вы не хотите, чтобы кто-то еще трогал. Конечно, если у вас есть кусочки кода, которые существуют в программе A, но не B, это довольно простой кандидат на разделение.

Answer 4

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