Минимизация количества DLL при сохранении модульности Composite WPF.

Question

Я работал над составным приложением WPF и только что прочитал несколько хороших рекомендаций о разбиении кода на сборки.Автор статьи выступает за минимизацию количества сборок там, где это возможно.

Как сбалансировать модульное приложение Composite WPF и минимизировать количество сборок?

Мой текущий проект я начал с создания модуля для каждой логической группы функций, что привело к созданию довольно большого количества (14) небольших сборок.Если бы мне пришлось провести рефакторинг и попытаться свести к минимуму сборки, я мог бы уменьшить его до 6, сохраняя при этом составную архитектуру WPF, но мне интересно, теряю ли я некоторую гибкость...возможно, мне следует вспомнить ЯГНИ.

Answer 1

Помимо ЯГНИ, помните также Разделение интересов и Ленивая загрузка шаблоны и используйте их в своих интересах.Нет смысла иметь меньше сборок, которые объединяют гораздо больше потенциально ненужных функций, относящихся к различным аспектам вашего приложения.Также имейте в виду, что гораздо проще поддерживать код, сохраняющий низкую связанность, поскольку вы рискуете вызвать ошибки, объединяя одни и те же функциональные возможности сборки, которые не принадлежат друг другу.

Возможно, вы захотите провести несколько тестов удобства использования в типичных сценариях использования вашего приложения и посмотреть, какие модули часто необходимы вместе, полагаются друг на друга или наследуются друг от друга и объединяют их в одни и те же сборки.Модули с непересекающимся функционалом — выбор приводит к загрузке одного ИЛИ другой, но никогда оба, особенно следует хранить в отдельных собраниях.

Answer 2

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