Should I Keep Business Objects Separate from the UI in WPF?

Question

WPF's view model oriented way of doing things makes it very tempting to just use business objects in the UI. Have you seen any issues with this? Why or why wouldn't you do this?

Answer 1

Not being a WPF guru, I can't be sure, but the usual reason for separating your M, V and C is so you can test the controller independent of the view, and the other way around.

Nothing stopping you, of course, but it should be a lot more testable (ie, unit tests) if it's separate. The MVP pattern, which is usually the one that MS promotes, is more geared around the presenter (ie, your WPF form) having more control, and thats fine too....

Answer 2

I guess I see it in a different light. I try to keep as much out of the UI as possible so I can use whichever UI presentation I need (ie. web, WPF, WinForms). The more business logic in the presentation layer, the more you may have to rewrite later if you migrate towards a different UI.

Answer 3

It's not a problem having business objects in the UI, as long as all you're doing is viewing them. In other words, if you want to change the properties of one, or delete one, or create a new one, you should be sending a message to the controller, presenter, or whatever to do that; and the results should then be updated in the view.

What you shouldn't do is use the ToString method of your objects (or any other methods or properties on your objects) to affect how they'll appear in the view. You should use DataTemplates to represent the view of your objects. If you need a more complex representation, you can use an IValueConverter to change the object into its visual representation.

Answer 4

The guidance from Microsoft's product teams (e.g., that's what the Blend team is using) is the Model-View-ViewModel architecture, a variant of the popular MVC pattern. A good starting point is http://blogs.msdn.com/johngossman/archive/2005/10/08/478683.aspx. There are also good articles by Dr. WPF on this topic.

Essentially, they advocate to create a ViewModel layer which uses binding-friendly business objects, such as ObservableCollection and the like.

Also, if you might eventually move to Silverlight 2, you might want to keep the business objects out of the UI layer so you can swap out UI technology (until WPF and Silverlight become source-code compatible).

Answer 5

Depending on your application architecture or the on the way you are planning to reuse your components and objects, you can choose a certain degree of independence from the user interface (in this case WPF).

Here is a sample of my experience:

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)

It's kind of bad that Microsoft has chosen to add some of the goodies to the System.Windows namespace, instead of, for example, to the System.ComponentModel where in my opinion they might have been more useful (by providing all of these important patterns not only to WPF but to the .NET Framework).

Of course this is just the beginning and many of us know that the thing will be evolving to the right direction in the end. (With the risk of going off-topic: Take silverlight 2.0 framework for example. It was a rushed release, with some of the objects in the WPF model missing and some not in their natural place.)

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!