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

Question

Я только что вернулся с совещания по проектированию, и мне задали вопрос о том, откуда у меня возникла одна из моих идей о том, как структурировать некоторые .dll-файлы проекта, который мы создаем.Честно говоря, я понятия не имею, откуда взялась эта «идея», она просто казалась мне естественным знанием.Однако было бы полезно, если бы я мог подкрепить эти мнения каким-нибудь документальным анализом.

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

ОБНОВЛЯТЬ:

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

Answer 1

Если у вас есть возможность, прочтите книгу Роберта К.Мартин:

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

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

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

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

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

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

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