Ресурсы для проектирования .dll структуры - PullRequest
0 голосов
/ 03 марта 2009

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

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

UPDATE:

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

1 Ответ

2 голосов
/ 03 марта 2009

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

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

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

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

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

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

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

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

...