TreeView + ViewModel = Goodness

[Josh Smith]

Sacha and I have been carrying out a very interesting e-mail thread recently about TreeView best practices.  All of our banter, and much prodding from Sacha, resulted in this article (of which I am extremely proud): http://www.codeproject.com/KB/WPF/TreeViewWithViewModel.aspx

Please vote kindly for it!  :)

Thanks,
Josh

[Corrado Cavalli]

This article is AMAZING!

Thanks a lot Josh, I really miss a book containing this kind of “real-life” applications.

 

Corrado

[Josh Smith]

Thank you, Corrado!  I'm glad you like it.  :)

[Laurent Bugnion [MVP, MCP]]

Hey Josh,

Great article. Very much in line with a lot of what I have been talking
about in my developers - designers presentations.

Here's a question: When I have the choice to implement
INotifyPropertyChanged (INPC) or to inherit from DependencyObject (all
other things being the same), I usually prefer the latest. I find the
ability to declare DependencyProperties more elegant than declare CLR
properties and raise the event.

Lately, however, I have been in contact with people who seems to prefer
the INotifyPropertyChanged approach. What puzzled me most is that
Silverlight clearly chose the INPC approach: You cannot derive from DO.

So what would you say, should I change my mind and rather use INPC for
my ViewModels?

Thanks,
Laurent

--
Laurent Bugnion [Microsoft MVP, MCP]
Software engineering, Blog: http://www.galasoft.ch
PhotoAlbum: http://www.galasoft.ch/pictures
Support children in Calcutta: http://www.calcutta-espoir.ch

[Josh Smith]

Thanks Laurent. 

Your question of INotifyPropertyChanged vs. DependencyObjects is very hard to answer in a generic fashion.  Each solution has pros/cons (of course) so the context in which they are used would probably determine the answer.  For example, are you building your app to be as "future-proof" as possible?  If so, you'll want to use INPC instead of DOs because the next UI platform probably won't work with DOs.  Etc.

If you want, list out some of our concerns and issues.  That way we can narrow down the question a bit and try to come to a more conclusive statement.

Josh

[Corrado Cavalli]

I personally don't like to tie my objectmodel to WPF, that's why I prefer
using INotifyPropertyChanged vs DependencyObject.
DependencyObject also ties ObjectModel to Fx 3.0 or greater while
INotifyPropertyChanged is available since V2.0.
ObjectModel should be a UI agnostic as possible.

Corrado

-----Original Message-----
From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com]

[Laurent Bugnion [MVP, MCP]]

Can you expand on why you think that the next platform won't work with DOs?

I don't really have a concern. It's more of a taste thing. I totally see
the value if INPC, I just had that gut feeling that deriving from DO was
more elegant. Now that I consider it, however, I am not that sure anymore.

I guess my question is: When does it make more sense to use DO than INPC
for data objects? Any specific scenario? When I try to think about it, I
only see more reasons to use INPC.

[Laurent Bugnion [MVP, MCP]]

Hi Corrado,

For an object model I totally agree. For a ViewModel, however, one can
argue that it is so tied to the View anyway that agnosticism is less
important.

I totally see your point about .NET 3.0 vs 2.0. This might be enough to
make me change my mind about using DOs.

As for DOs being tied to WPF... while it is true (being part of
System.Windows and all), I feel that they have a much broader possible
use than "just" for UI.

Same question as for Josh: Do you see a data scenario where deriving
from DO makes more sense than using INPC?

Thanks!
Laurent

[Josh Smith]

I suppose if all concerns over being UI-agnostic are put aside, the question of INotifyPropertyChanged vs. DependencyObject becomes a matter of personal preference.  I can see the merit in using built-in support for property change notifications, sparse storage, property change callbacks, validation callbacks, and default values.  That is certainly a lot of great functionality to get out of the box.  However, on the other hand, the simplicity of just implementing INPC makes the code cleaner and easier to debug.

I don't have a definite answer for you.  I suppose I should say at this point, I have never chosen to use DO for my ViewModel objects, but, I will try it sometime!  It's all good. :)

Josh

[Josh Smith]

> Can you expand on why you think that the next platform won't work with DOs?

Not really.  :)  I just assume that something as core to the WPF framework will be too "specific" for the next big platform to use.  Who knows, maybe DO will become the next INotifyPropertyChanged, spanning the generations of UI platforms.

> When does it make more sense to use DO than INPC for data objects?

IMO, you should never use DO for data objects, assuming by "data objects" you're referring to things that are passed between tiers.  DO is not serializable, for starters.  Also, I believe strongly in the use of Data Transfer Objects (DTOs), which are essentially lightweight, brain-dead structures that are quickly serialized and transferred over the wire.

Josh

[Laurent Bugnion [MVP, MCP]]

That makes sense too. I also didn't really see one case where DO makes
more sense for non-UI specific scenarios. As for the VM... well, yeah
there is a lot of goodies in DOs for sure, like coercion,
propertychangedcallbacks, etc... I guess that as usual in engineering,
there is no definite right choice :)

I'd love to hear what our good doctor has to say about all that...

Josh Smith wrote:
> > Can you expand on why you think that the next platform won't work
> with DOs?
>

> Not really. :) I just assume that something as core to the WPF
> framework will be too "specific" for the next big platform to use.
> Who knows, maybe DO will become the next INotifyPropertyChanged,
> spanning the generations of UI platforms.
>
> > When does it make more sense to use DO than INPC for data objects?
>
> IMO, you should never use DO for data objects, assuming by "data
> objects" you're referring to things that are passed between tiers. DO
> is not serializable, for starters. Also, I believe strongly in the
> use of Data Transfer Objects (DTOs), which are essentially
> lightweight, brain-dead structures that are quickly serialized and
> transferred over the wire.
>
> Josh
>

--

[Josh Smith]

"Paging Dr. WPF.  Paging Dr. WPF.  Please report to the WPF Rehab facility at once."  :)

[Corrado Cavalli]

When I speak about WPF databinding I keep seeing people suggesting to use
DPs on ObjectModels because of automatic change notification forgetting
about the WPF overhead.
About ViewModel: It doesn't have to be tied to WPF, in Josh's Treeview
sample the only link to WPF is the SearchCommand property exposed by
FamilyTreeViewModel otherwise it could probably reused (in totally different
mode) in other technologies.
I also don't like the unused overhead (e.g. Dispacther) that DP brings
together just to notify that a property has changed, being viewmodels
instances quite huge, the lighter they are, the better is application.
For other cases that we all know (Coercion,Validation,Value Propagation,
etc...) of always recommend DPs.

Just my two euro cents :-)

[Laurent Bugnion [MVP, MCP]]

Your opinion is much more invaluable than when it was "just your two
liras" :)

Corrado Cavalli wrote:
> When I speak about WPF databinding I keep seeing people suggesting to use
> DPs on ObjectModels because of automatic change notification forgetting
> about the WPF overhead.
> About ViewModel: It doesn't have to be tied to WPF, in Josh's Treeview
> sample the only link to WPF is the SearchCommand property exposed by
> FamilyTreeViewModel otherwise it could probably reused (in totally different
> mode) in other technologies.
> I also don't like the unused overhead (e.g. Dispacther) that DP brings
> together just to notify that a property has changed, being viewmodels
> instances quite huge, the lighter they are, the better is application.
> For other cases that we all know (Coercion,Validation,Value Propagation,
> etc...) of always recommend DPs.
>
> Just my two euro cents :-)
> Corrado
>
>

--

[Corrado Cavalli]

Given the situation, I'd prefer if I could still use Lira's instead of
Euro's but you know... ;-)

-----Original Message-----
From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com]
On Behalf Of Laurent Bugnion [MVP, MCP]
Sent: venerdì 23 maggio 2008 15:08
To: wpf-di...@googlegroups.com
Subject: Re: TreeView + ViewModel = Goodness

[Jeremiah Morrill]

These are my favorite email threads.  Questions I was too afraid to ask, being answered and/or discussed.

 

Also back to the OT.  Josh and Sacha, there seems to be some 6th sense you guys share with the WPF "world".  Yesterday, I was just discussing architectural patterns, specifically MVVM with WPF...arguing that is is not a Microsoft ploy to take something well known (MVC) and make it proprietary, as to employ developer lock-in and ultimately dominate the world and enslave humanity.  So Josh, thank you for the article, the timing was impeccable (for me).

-Jer

[Josh Smith]

My crystal ball indicated that you needed some ammo.  I've got your back, Jer.

[Jeremiah Morrill]

LOL,  Thanks..yes this is the nuke that won the war :)...Thankfully there were no casualties...besides maybe an ego or two.

[Josh Smith]

show no mercy

[Brennon Williams]

What an awesome thread guys…

 

Great questions and great answers… I found your article impeccable and very thought provoking Josh; like Laurent I favoured DO’s previously.

 

I guess from my side of things (which is now purely UI layer) I sometimes don’t think deep enough in terms of how the object model is being constructed… a sort of “not my backyard anymore” type scenario, but given the importance of a performant light weight OM coming into my house, I think what your article, and this subsequent thread has done for me is make me reassess the influences on a high performance UI.

 

Cheers guys

[Josh Smith]

Brennon,

I used to find myself sometimes slipping into that mindset, where I focused almost exclusively on the UI layer, at the expense of the other layers.  It's easy to do, especially if that really is all that you are working with.  It was a habit easily broken when people starting leaving comments on my blog posts like "Hey pipe dreamer, this doesn't make any damn sense in the big picture."  :)

Josh

[Dr. WPF]

> "Paging Dr. WPF.  Paging Dr. WPF.  Please report to the WPF Rehab facility
> at once."  :)

Yikes!  I'm the one whose going to need rehab by the time I get through all these threads!  I neglect my Disciples inbox for a few days and it nearly brings down my mail server.  ;-) 

With respect to the question of whether to use INotifyPropertyChanged vs a DependencyObject, I almost always use a lightweight CLR object with INotifyPropertyChanged.  This decision is typically based on the desire to keep the view model as simple as possible and to support serialization to/from data classes.  It also allows the objects to easily be passed across the wire (via remoting, WCF web services or whatever... again serialization).

But there are definitely valid reasons to use a DependencyObject-based view model too.  Especially if you need the other goodness afforded by DPs (value coersion, etc).  And the framework has gone to great lengths to optimize the property engine for certain databinding scenarios. 

If your primary concern is the speed of bindings (and you don't mind a little memory overhead for a heavier object), you will typically see the best binding perf when binding DPs to other DPs... especially if many different DPs are the target to a single DP source.  This is because the property engine maintains a list of all dependencies for a property (hence the name :)) and when the property's value changes, the framework can proactively update all of the other dependent property values. 

In the case of binding to CLR objects via INotifyPropertyChanged, the framework still keeps a list of listeners, but each such listener simply gets notified that the property changed and must then query the object directly to get the new value.

That said, I've rarely seen a need for the extra binding perf in "real" applications.... Most of the time, there just aren't that many dependencies for a single property and INotifyPropertyChanged is very nearly as fast as a DP in that case.

Dr. WPF - Online Office at http://www.drwpf.com/blog/

[Josh Smith]

Great insight.  Thanks doc.

[Marlon Grech]

thanks doc.... impressive as usual....

man...I feel so stupid when I read an answer from the Dr...
Dr. WPF can I ask you a question? What do you eat? Is it XAMLified chickens?

--
Regards
Marlon
Blog - http://marlongrech.wordpress.com/
WPF Controls Library - http://www.codeplex.com/avaloncontrolslib

[rudigrobler]

Josh,

My question is not related to IPNC vs DO... but more about the
implementation details of IPNC...

Do you still think it is important to cache the
PropertyChangedEventArgs (Like in your BindableObject)?

My 2c... I still prefer the cleaner IPNC than the DO! I big
concideration for me is also the fact that the IPNC is serializable!!!

Tnx,

Rudi

[Corrado Cavalli]

Thanks Doc, I’ll save this post and I’ll use it in my WPF classes J

 

Corrado

 

From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On Behalf Of Dr. WPF
Sent: sabato 24 maggio 2008 01:37
To: wpf-di...@googlegroups.com
Subject: Re: TreeView + ViewModel = Goodness

 

> "Paging Dr. WPF.  Paging Dr. WPF.  Please report to the WPF Rehab facility
> at once."  :)

[Josh Smith]

Rudi,

Someone posted a comment on my blog post about "BindableObject"  that shows how to remove the need for caching the args, by having just ONE instance whose PropertyName can be swapped out.  I think that's the best way to do it.

[Bill Kempf]

I've recently been leaning more towards DependencyObject.  Too much power in DO/DP to not seriously consider using it in your BOs.  Yes, there are tradeoffs to consider in this choice... but I don't think that wanting to not tie your BOs to WPF is one of them.

 

First, how many business/domain models can get away with out having collections?  If they have collections, can you really get by without INotifyCollectionChanged?  That interface is defined in WPF, so you already have a tie.  Further, both INotifyCollectionChanged and DependencyObject are defined in the same assembly: WindowsBase.

 

Since WPF is part of the framework, the only concern with referencing any of its assemblies is a concern for the runtime overhead.  WindowsBase.dll currently clocks in at 1,176 KB, so I'm not too worried about the overhead.  It might have been nice to have this and INotifyCollectionChanged/ObservableCollection in another assembly (maybe even in one of the core BCL assemblies), but I'm not going to sweat using them in the domain model.

War is peace. Freedom is slavery. Bugs are features.

[Josh Smith]

That's an excellent argument in favor of using DO, Bill.  You're right, the 1,176 KB "overhead" of an indelible part of the .NET Framework is nothing.  I suppose the issue, INotifyPropertyChanged vs. DependecyObjects, really boils down to personal preference. 

Josh

[corrado...@gmail.com]

> That's an excellent argument in favor of using DO, Bill.  You're right, the
> 1,176 KB "overhead" of an indelible part of the .NET Framework is nothing.
> I suppose the issue, INotifyPropertyChanged vs. DependecyObjects, really
> boils down to personal preference.

Agree with you, It's just a matter of preference but:

-I personally don't want to ask BO's developers to know WPF concepts
-Being not able to port my BO's to compact framework or OS
running .NET Fx 2.0
-From a OOP point of view i simpy don't think is correct to have an
invoice class inheriting from a DispatcherObject
-Having problems if i want to serialize my BO's or interacting with
LINQ or EF.

From my POV a dependencyobject is something that has interaction with
UI (and we have ViewModels for this), all the rest should be separated
as much as possible from any UI concept.

:-)

Corrado

[Karl Shifflett]

Everyone,

I'm coming in at the end of the line. I would consider very long and hard before deriving business objects from Dependency Object.

You could run into problems with Silverlight, LINQ to SQL, Winforms, ASP.NET, the new Entity Framework, etc. You may also introduce threading issues.

Karl's vote is, "Clean and mean."

________________________________

Josh

Software engineering, Blog: http://www.galasoft.ch <http://www.galasoft.ch/>
PhotoAlbum: http://www.galasoft.ch/pictures
Support children in Calcutta: http://www.calcutta-espoir.ch <http://www.calcutta-espoir.ch/>

[Bill Kempf]

I can't agree with your first bullet point.  All the rest are very valid.  I still think there's a time and a place for a DependencyObject as the base for your business/domain objects, though.

[Laurent Bugnion [MVP, MCP]]

Hi Corrado

I agree with all your points, but my original question was really for
the ViewModel. This is where I think it makes sense to use DOs.

Greetings,
Laurent

corrado...@gmail.com wrote:
> Agree with you, It's just a matter of preference but:
>
> -I personally don't want to ask BO's developers to know WPF concepts
> -Being not able to port my BO's to compact framework or OS
> running .NET Fx 2.0
> -From a OOP point of view i simpy don't think is correct to have an
> invoice class inheriting from a DispatcherObject
> -Having problems if i want to serialize my BO's or interacting with
> LINQ or EF.
>
> From my POV a dependencyobject is something that has interaction with
> UI (and we have ViewModels for this), all the rest should be separated
> as much as possible from any UI concept.
>
> :-)
>
> Corrado
> >
>
>
>
>

--

[Corrado Cavalli]

Yes I know your question very well but being the viewmodel an adapter around
the original entity I personally prefer not depending on DependencyObject
(as Karl said, I like it cleanest as possible), but here I'm more open and I
agree that using Dos could help.

Good luck for your next talk ;-)
Corrado

-----Original Message-----
From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com]
On Behalf Of Laurent Bugnion [MVP, MCP]
Sent: martedì 27 maggio 2008 21:07
To: wpf-di...@googlegroups.com
Subject: Re: TreeView + ViewModel = Goodness

[Laurent Bugnion [MVP, MCP]]

Thanks :) I am rehearsing the talk now, just took a short break to see
what you wrote :)

[Laurent Bugnion [MVP, MCP]]

Ah, by the way, Josh, I am using Fodder V1 versus Fodder V2 in my talk
:) Just to demonstrate what happens how cool the designer-developer
workflow can be :) I hope you don't mind if I joke about the "developer
skin" :) I also will take the occasion to mention the contest :)

[Josh Smith]

Cool! 

BTW - it's Podder, not Fodder.  Fodder is what you feed to farm animals.  :)

josh

[Josh Smith]

Forgot to add...I don't care at all if you mock my feeble attempt at creating a skin.  That's fine.  I'll just cry myself to sleep every night, that's all. :P  just kidding...

[Laurent Bugnion [MVP, MCP]]

Oh damn *L* Can't believe I wrote that. Of course I know it's
PPPPPodder. Hope that doesn't disqualifies me as a judge now :)

To be fair, I include myself in the group of "developers who cannot
design" :) And I explicitly mention that in the talk.

Josh Smith wrote:
> Forgot to add...I don't care at all if you mock my feeble attempt at
> creating a skin. That's fine. I'll just cry myself to sleep every
> night, that's all. :P just kidding...
>
> On Tue, May 27, 2008 at 4:18 PM, Josh Smith <flappl...@gmail.com
> <mailto:flappl...@gmail.com>> wrote:
>
> Cool!
>

> BTW - it's *P*odder, not *F*odder. Fodder
> <http://en.wikipedia.org/wiki/Fodder> is what you feed to farm

> > corrado...@gmail.com <mailto:corrado...@gmail.com>

[Josh Smith]

So, being a member of a group gives you the right to mock that group with immunity?  Good to know!  ;)

[Laurent Bugnion [MVP, MCP]]

That's what I signed for, yep.

Josh Smith wrote:
> So, being a member of a group gives you the right to mock that group
> with immunity? Good to know! ;)
>
> On Tue, May 27, 2008 at 4:23 PM, Laurent Bugnion [MVP, MCP]
> <lau...@galasoft.ch> wrote:
>
>
> Oh damn *L* Can't believe I wrote that. Of course I know it's
> PPPPPodder. Hope that doesn't disqualifies me as a judge now :)
>
> To be fair, I include myself in the group of "developers who cannot
> design" :) And I explicitly mention that in the talk.
>
> Josh Smith wrote:
> > Forgot to add...I don't care at all if you mock my feeble attempt at
> > creating a skin. That's fine. I'll just cry myself to sleep every
> > night, that's all. :P just kidding...
> >
> > On Tue, May 27, 2008 at 4:18 PM, Josh Smith
> <flappl...@gmail.com <mailto:flappl...@gmail.com>

> > <mailto:flappl...@gmail.com <mailto:flappl...@gmail.com>>>

> > <mailto:wpf-di...@googlegroups.com

> <mailto:wpf-di...@googlegroups.com>>
> > > Subject: Re: TreeView + ViewModel = Goodness
> > >
> > >
> > > Hi Corrado
> > >
> > > I agree with all your points, but my original question was
> > really for
> > > the ViewModel. This is where I think it makes sense to
> use DOs.
> > >
> > > Greetings,
> > > Laurent
> > >
> > > corrado...@gmail.com

> <mailto:corrado...@gmail.com> <mailto:corrado...@gmail.com

[Brennon Williams]

" To be fair, I include myself in the group of "developers who cannot
design" :) And I explicitly mention that in the talk."

At least you admit this Laurent... more power to you!

Can we listen to your talk during or after the event?

-----Original Message-----
From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com]
On Behalf Of Laurent Bugnion [MVP, MCP]
Sent: 27 May 2008 21:24
To: wpf-di...@googlegroups.com
Subject: Re: TreeView + ViewModel = Goodness

Oh damn *L* Can't believe I wrote that. Of course I know it's
PPPPPodder. Hope that doesn't disqualifies me as a judge now :)

[Laurent Bugnion [MVP, MCP]]

Unfortunately I don't think it will be recorded, but I will post the
slides and the demo code on my blog. It's an interesting talk, which
concentrates explicitly on the strength of WPF versus Silverlight, AIR
and other RIAs. The talk was "ordered" by Microsoft: In the same
conference, there are talks about AIR, Java, etc... and also
Silverlight, and MSFT wanted to end with a reminder that .NET has an
explicit "edge" against RIAs, and thus also against Silverlight. I love
to see WPF back in the middle of the game, and that's why I talk of
"Ultra Rich Applications" with WPF :)

Greetings,
Laurent

[Brennon Williams]

Great stuff!

Cheers Laurent and good luck with it all.

[rudigrobler]

I just released a blog post that briefly touches on DO vs INPC

http://dotnet.org.za/rudi/archive/2008/06/23/myhealth.aspx

Rudi

PS. If your BO or Model is not backed by some persistent data store,
like a DB, don't use DO's persisting a non serializable object sucks!!!

[rudigrobler]

A short article on how to "serialize" a DependencyObject

http://dotnet.org.za/rudi/archive/2008/06/24/quot-serialize-quot-a-dependencyobject.aspx

[rudigrobler]

Hi Josh,

I know that XAMLWritter/Reader are slow... Do you know if it is
possible from code to "save" a object as BAML? And If possible, would
that increase the performance?

On Jun 24, 9:05 pm, rudigrobler <rudi.grob...@gmail.com> wrote:
> A short article on how to "serialize" a DependencyObject
>

> http://dotnet.org.za/rudi/archive/2008/06/24/quot-serialize-quot-a-de...

>
> On Jun 23, 10:16 am, rudigrobler <rudi.grob...@gmail.com> wrote:
>
>
>
> > I just released a blog post that briefly touches on DO vs INPC
>
> >http://dotnet.org.za/rudi/archive/2008/06/23/myhealth.aspx
>
> > Rudi
>
> > PS. If your BO or Model is not backed by some persistent data store,

> > like a DB, don't use DO's persisting a non serializable object sucks!!!- Hide quoted text -
>
> - Show quoted text -

[rudigrobler]

Just Checked, their is a BamlBinaryWritter and BamlBinaryReader...
Will try?

[Josh Smith]

Let us know the result...