MVVM и предотвращение Монолитного объекта Бога
Я нахожусь на этапе завершения крупного проекта, который имеет несколько больших компонентов: получение изображений, обработка изображений, хранение данных, фабрика ввод-вывод (проект автоматизации) и несколько других.
Каждый из этих компонентов довольно независим, но для проекта работать в целом мне нужен по крайней мере один экземпляр каждого компонента. Каждый компонент также имеет ViewModel и Представление (WPF) для контроля состояния и изменения вещей.
Мой вопрос является самым безопасным, самым эффективным, и большая часть удобного в сопровождении метода инстанцирования всех этих объектов, подписка одного класса к Событию в другом и наличия общего ViewModel и Представления для всего этого.
Был бы он лучше всего, если у меня есть класс под названием Бог, который имеет частный экземпляр всех этих объектов? Я сделал это в прошлом и сожалел о нем.
Или было бы лучше, если бы Бог полагался на экземпляры Singleton этих объектов сдвинуться с мертвой точки.
С другой стороны, если Program.cs (или везде, где Основной (...)) инстанцируют всех этих компонентов, и передают их Богу как параметры и затем позволяют Ему (хихиканье) и Его соглашение ViewModel с подробными сведениями выполнения, это проектирует.
Любые другие предложения я хотел бы услышать.
Спасибо!
5 ответов
Я предпочитаю использовать ViewModel с помощью ViewModelLocater. По сути, это объект Бога, как вы подразумеваете, но его единственная ответственность - создать каждую ViewModel и сохранить ссылку на нее. Я обычно добавляю VML к ресурсам приложения, и каждое представление отвечает за настройку его DataContext на правильную ViewModel. Если вы подписываете несколько событий, вы можете либо подключить их к VML вручную, либо создать виртуальную машину, которая сначала генерирует события, и передать их зависимой виртуальной машине в своем конструкторе.
Взгляните на некоторые фреймворки внедрения зависимостей, такие как Unity (который использует CAL), Castle Windsor или Spring.NET.
Эти проблемы хорошо решаются с помощью "Composite Application Library" (она же Prism) от Microsoft - фреймворка для разработки составных WPF-приложений:
http://msdn.microsoft.com/en-us/library/ff647752.aspx
http://msdn.microsoft.com/en-us/library/ff648611.aspx
Составление представлений: Prism имеет концепцию окна-оболочки приложения и менеджера регионов. Оболочка выступает в качестве базовой страницы макета, где вы определяете именованные регионы-держатели, например, "MainMenu" и "TabInterface". Вы оборачиваете ссылки на ваши представления и модели представлений в классы модулей, например, "MainMenuModule" и "TabInterfaceModule", и определяете, с каким регионом должен быть связан модуль. Prism создаст ваши представления и внедрит их в регионы оболочки при запуске приложения. Это позволяет вам компоновать ваши представления независимо друг от друга.
Связь между моделями представлений: Prism поддерживает модель посредника под названием "Агрегатор событий". В принципе, вы можете публиковать и подписываться на сообщения через агрегатор событий из ваших вью-моделей. Это позволяет вью-моделям свободно общаться через сообщения, вместо того, чтобы знать друг о друге и подключать события.
Prism пропагандирует и поддерживает паттерны для разработки компонентов независимо друг от друга в свободной связке, без введения объектов Бога и чрезмерной связи. Большой частью Prism также является использование IOC и инъекции зависимостей, поэтому модульное тестирование также становится намного проще.
Я нашел следующую статью хорошим практическим введением в использование Prism и MVVM:
Вы можете использовать Контроллеры (ApplicationController, Use-Case Controllers) вместо класса «God». Контроллеры несут ответственность за создание объектов ViewModel и являются посредниками между ними.
Как это работает, показано в проекте WPF Application Framework (WAF) .
Надеюсь, я хорошо понял ваш вопрос. Я думаю, что использование God ViewModel не очень хорошая идея. Лучше иметь одну смоделку представлений для каждого из ваших представлений и создать экземпляры всех связанных режимов просмотра в этой смоделочной. затем вы можете использовать посредник для отправки сообщения между режимами просмотра этого представления и другими представлениями, safly. Кроме того, я предлагаю использовать команды wpf вместо событий.Вы можете найти большую статью о посреднике в здесь.