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

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

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

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

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

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

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

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

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

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

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

I've worked with WPF just a little, on a relatively small project, where the business layer was already defined, and we just needed to create a user interface. Of course, the interface had defined it's own rules and objects that it was working with, and because the application was defined just for UX we have chosen to create our own specific objects, mostly by extending DependencyObject (mainly for Data Binding purposes).

Some people may argue that it's not ok to use dependency objects because they not are serializable (actually they are - to XAML), they bring a dependency to WPF (the System.Windows namespace), and some other arguments. Also, DependencyObjects support other options, like attached properties and dependency properties. Others might like to use for example INotifyPropertyChanged if it makes sense, and others might say that all of these patterns don't belong in other layer than UI. (If you want to learn more there are some good WPF data binding articles in the MSDN library, including best practices for perfomance and for user interface)

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

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

In the end, everything depends on you, your programming style, your architectural decisions and your knowledge of the technology.

If it seems more natural to do it in a way, than by the book, think why you should and why should you not before taking any decision!