WPF

Recently I started to work on a new project in our company that is using WPF technology. As a web developer with almost no experience with desktop applications I find it interesting and challenging at the same time (statefull environment,  no need in intermediate DTO objects, rich UI support, XAML abilities that are beyond regular markup capabilities, etc). Yet there are many questions that have an answer, but feel very weird. A few of those for example

  1. I have a domain object Client. When binding its' properties, I have to implement INotifyPropertyChanged and "pollute" the code with Notifications for UI. When a property is calculated (getter only), another property has to do the notification, which may end up in cascading notification. As a result of this, the responsibility of a Client now also includes UI notification responsibilities. Feels wrong.
  2. XAML - expressing if not everything, but 99% in XAML is cool, but this brings the question of concerns as well. Should bindings be determined in code and not markup? It's easier and faster to refactor code, rather than markup.
  3. VS.NET support for XAML - well, if not R#, I honestly would not manage to do a lot. SP1 does help, but R# is still pulling off a lot more. Seems like IDE is not ready for the XAML yet. Blend 2.5 is an option, but just the designer, which makes code development a bit challenged.
  4. Resources - there are lots of them, and at the same time not many that are nicely arranged/grouped/catalogued. I loved Prism  for WPF - structured, unified, dealing with real-life applications issues. Also connects between WPF and other things no project can exist without.
  5. Updated: Controls support - No DatePicker or Calendar control. There's a lot of attempts to provide a substitute, but IMO MS should care for that as a part of the bandle. TabControl - a bug with validation and switching tabs (validation is not happening). For a control like tabs, this is a bit sloppy.

For myself, I think I need to dig dipper to understand the core concepts and principles of WPF/XAML. The implementation details will be less significant if I grasp the concepts first (as always). You are welcome to share your opinions or advices in terms of where to dig first.

4 Comments

  • I would strongly disagree that WPF negates the need to DTOs. Maybe DTOs have been too much associated with web development but WPF like any other UI system can benefit from a presentation model abstracting it from the domain model. Having used domain model entities mapped to the database using an ORM I would definitely use a presentation model to avoid UI blocking calls because a responsive UI is of most importance.

  • I understand where you're coming from in regards to INotifyPropertyChanged, but it is useful for more than just UI notification. Because you're now working in a stateful environment you can use change notifications to recalculate derived properties. If a Invoice object has a BindingList, when the Quantity or Price property changes on the Item you can recalulate the TotalPurchasePrice on the Invoice. I prefer using BindingList (in system.componentmodel) instead of ObservableCollection because it will subscribe to the PropertyChanged event for you, so your objects only need to subscribe to BindingList.ListChanged to get all notifications.

  • I am in a similar position... getting to grips with what should be the best practices in WPF. Should DTOs be used? Is it worth the hassle? Is there a nice way to keep your validation logic in your domain objects?

    One tip I have is that you can avoid polluting your domain objects with INotifyPropertyChanged by using a the NotifyPropertyChangedAttribute that comes with PostSharp in their examples. This works well as all you have to do is put this attribute on your class and it implements INotifyPropertyChanged for you in a post-compile step.

  • @Geoff,
    my personal conclusion on this was - use dtos to databind UI and perform updates, use convertes to validate/invalidate data, but still on dtos, and later, propagate changes into domain (when and if data is valid). Then there's no problem to "polute" a dto. The issue becomes that DTO is no longer a pure DTO... thanks for the tip on NotifyPropertyChangedAttribute - didn't know about that one.

Comments have been disabled for this content.