Должен ли я хранить бизнес-объекты отдельно от пользовательского интерфейса в 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 для представления вида ваших объектов. Если вам нужно более сложное представление, вы можете использовать IValueConverter для изменения объекта в его визуальное представление.

Answer 4

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

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

Answer 5

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

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

  

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

     

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

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

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

  

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

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