Должен ли я хранить бизнес-объекты отдельно от пользовательского интерфейса в WPF?

Question

Ориентированный на модель представления способ работы WPF делает весьма заманчивым использование бизнес-объектов в интерфейсе пользователя. Вы видели какие-либо проблемы с этим? Почему или почему бы тебе не сделать это?

Answer 1

Руководством групп разработчиков продуктов Microsoft (например, именно этим пользуется команда Blend) является архитектура Model-View-ViewModel, вариант популярного шаблона MVC. Хорошей отправной точкой является http://blogs.msdn.com/johngossman/archive/2005/10/08/478683.aspx.. На эту тему также есть хорошие статьи доктора WPF.

По сути, они выступают за создание слоя ViewModel, который использует дружественные для привязки бизнес-объекты, такие как ObservableCollection и т. П.

Кроме того, если вы в конечном итоге перейдете на Silverlight 2, возможно, вы захотите сохранить бизнес-объекты вне уровня пользовательского интерфейса, чтобы можно было менять технологию пользовательского интерфейса (пока WPF и Silverlight не станут совместимыми с исходным кодом).

Answer 2

Полагаю, я вижу это в другом свете. Я стараюсь держать как можно больше от пользовательского интерфейса, чтобы я мог использовать любую презентацию, которая мне нужна (например, веб, WPF, WinForms) Чем больше бизнес-логики на уровне представления, тем больше вам придется переписать позже, если вы перейдете на другой пользовательский интерфейс.

Answer 3

Нет проблем с наличием бизнес-объектов в пользовательском интерфейсе, если все, что вы делаете, это просмотр их. Другими словами, если вы хотите изменить свойства одного, или удалить один, или создать новый, вы должны отправить сообщение контролеру, докладчику или кому-либо еще, чтобы сделать это; и результаты должны быть обновлены в представлении.

То, что вы не должны делать, это использовать ToString метод ваших объектов (или любые другие методы или свойства ваших объектов), чтобы влиять на то, как они будут отображаться в представлении. Вы должны использовать DataTemplate s для представления вида ваших объектов. Если вам нужно более сложное представление, вы можете использовать IValueConverter, чтобы изменить объект в его визуальное представление.

Answer 4

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

Вот пример моего опыта:

Я немного поработал с WPF, относительно небольшой проект, где бизнес-уровень уже определен, и нам просто нужно было создать пользователя интерфейс. Конечно, интерфейс определили свои правила и объекты что он работал, и потому что приложение было определено только для UX мы решили создать свой собственный конкретные объекты, в основном путем расширения DependencyObject (в основном для Data Binding целей).

Некоторые люди могут утверждать, что это не хорошо использовать объекты зависимости, потому что они не являются сериализуемыми (на самом деле они являются XAML), они приносят зависимость от WPF ( System.Windows пространство имен) и некоторые другие аргументы. Также, DependencyObjects Поддержка других параметры, такие как прикрепленные свойства и свойства зависимостей . другие может использовать например INotifyPropertyChanged, если это имеет смысл, и другие могут сказать, что все эти шаблоны не принадлежат другой слой, чем пользовательский интерфейс. (Если вы хотите узнать больше, есть какая-то хорошая WPF привязка данных статьи в библиотеке MSDN, включая лучшие практики для производительность и для пользовательского интерфейса)

Плохо, что Microsoft решила добавить некоторые вкусности в пространство имен System.Windows вместо, например, в System.ComponentModel, где, по моему мнению, они могли бы быть более полезными (предоставляя все эти важные шаблоны не только для WPF, но и для .NET Framework).

Конечно, это только начало, и многие из нас знают, что в конце эта вещь будет развиваться в правильном направлении. (С риском уйти не по теме: возьмите, например, платформу silverlight 2.0. Это был спешный выпуск, в котором некоторые объекты в модели WPF отсутствовали, а некоторые не были в своем естественном месте.)

В конце концов, все зависит от вас, вашего стиля программирования, ваших архитектурных решений и ваших знаний о технологиях.

Если это кажется более естественным, чем в книге, подумайте why you should и why should you not, прежде чем принимать какое-либо решение!

Answer 5

Не будучи гуру WPF, я не уверен, но обычная причина разделения ваших M, V и C состоит в том, что вы можете тестировать контроллер независимо от вида и наоборот.

Ничто не мешает вам, конечно, но это должно быть намного более тестируемым (то есть, модульными тестами), если оно отдельное. Шаблон MVP, который, как правило, продвигает MS, больше ориентирован на презентатора (т. Е. На вашу форму WPF), обладающего большим контролем, и это тоже хорошо ....