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

Question

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

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

UPDATE:

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

Answer 1

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

Agile Principles, Patterns, and Practices in C# (Это новая версия специально ориентирована на .Net)

Существует глава посвящена компоненту дизайн, который (возможно) отвечает на ваш вопрос.

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

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

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

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

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