Ресурсы для проектирования.dll структуры

Question

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

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

ОБНОВИТЬ:

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

Answer 1

Если у вас есть шанс, взгляните на книгу Роберта С. Мартина:

Agile Принципы, Шаблоны и Практики в C# (Это новая версия, специально предназначенная для.Net)

Есть глава, посвященная разработке компонентов, которая (вероятно) отвечает на ваш вопрос.

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

• Сборки - это единицы или повторное использование: если есть классы, которые должны использоваться вместе, они идут в одной сборке.

• Сборки являются единицами изменения: если есть классы, которые не должны изменяться по той же причине, они, вероятно, не должны находиться в одной сборке.

• Сборки являются единицами развертывания: если есть классы, которые должны быть физически развернуты в одном и том же месте, они, вероятно, должны находиться в одной сборке.

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