View Models: POCOs versus DependencyObjects

[Kent Boogaart]

Hi all,

I've posted my thoughts on the subject of POCO vs. DependencyObject-
based view models here: http://kentb.blogspot.com/2009/03/view-models-pocos-versus.html

As always, your feedback would be most welcome.

Best,
Kent

[Corrado Cavalli]

I'm on your side, I always prefer POCO vs DependencyObject.
One thing I like on DPs is the automatic thread marshaling that allows you
to update a VM property from a secondary thread w/o Invoke issue.

-Corrado

[Mike Brown]

Good post Kent, I wrote a little utility to do strongly typed INPC notifications with expressions so I definitely like your fluent INPC binding.

 

I think this was a big deal back in 06 when Charles Petzold argued that your domain objects should be dependency objects. It was before the VM pattern really gained traction. I didn't agree with that viewpoint back then...you COULD make a case for making your VM as a DO (DP coercion is a compelling argument for, especially for really complex intricate UI interactions). But I wouldn't make my VMs as DOs the default.

[Karl Shifflett (Comcast)]

Kent,

Nice post.

Cheers,

k-dawg

[Laurent Bugnion, GalaSoft [MVP, MCP]]

Very good post. It summarizes in one handy place many experiments I did (and
a few I missed) ;)

Laurent

-----Original Message-----
From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com]
On Behalf Of Kent Boogaart
Sent: Thursday, March 26, 2009 8:21 PM
To: WPF Disciples
Subject: [WPF Disciples] View Models: POCOs versus DependencyObjects

Hi all,

Best,
Kent

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.0.238 / Virus Database: 270.11.29/2024 - Release Date: 03/26/09
07:12:00

[Colin Eberhardt]

Thanks Kent,

That was a really interesting read, especially because I have not, as
of yet, embarked on a MVVM application myself. It will surely save me
some precious hours!

One thing that I find really interesting is the final nail in the
DependencyObject coffin, that of code readability. Being a relatively
new disciple, I am not sure whether this has been discussed here
before but ...

"Why are Dependency Properties so damn verbose and ugly?"

OK ... I do know the answer to that question, but it doesn't stop me
muttering it under my breath every now and again when I make a trivial
mistake in my DP definition that goes untraced. I have also started
encouraging a few of my collegues to start learning WPF and they all
go through the same phase of questioning why DPs should be this way.

I think it would be hugely beneficial to new starters of WPF if DPs
were defined declaritively in some way, perhaps as attributes
associated with a CLR property. Or, perhaps more viable, as simple VS
designer that generates a partial class with the DPs for a DO.

I haven't really thought through what might be a suitable
mechanism ... but I do feel that something along these lines would be
hugely beneficial.

Regards,
Colin E.

[David Anson]

A dude on our team (no, it's not Scott Hanselman) who's big into T4 thinks that T4 templates (layman's summary: original C-style preprocessor macros FTW!) are the answer here.

Here's more on T4: http://www.hanselman.com/blog/T4TextTemplateTransformationToolkitCodeGenerationBestKeptVisualStudioSecret.aspx

-----Original Message-----
From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On Behalf Of Colin Eberhardt
Sent: Thursday, March 26, 2009 10:54 PM
To: WPF Disciples

[Colin Eberhardt]

Hi David,

Funnily enough I explored the idea further and landed on the T4 MSDN
pages ... I might just give it a go ...

Thanks,
Colin E.

On Mar 27, 6:18 am, David Anson <david...@microsoft.com> wrote:
> A dude on our team (no, it's not Scott Hanselman) who's big into T4 thinks that T4 templates (layman's summary: original C-style preprocessor macros FTW!) are the answer here.
>

> Here's more on T4:http://www.hanselman.com/blog/T4TextTemplateTransformationToolkitCode...

[Sacha Barber]

Good post, like it.

> Date: Thu, 26 Mar 2009 12:21:24 -0700
> Subject: [WPF Disciples] View Models: POCOs versus DependencyObjects
> From: ken...@internode.on.net
> To: wpf-di...@googlegroups.com

---

Windows Live Hotmail just got better. Find out more!

[Marlon Grech]

I go for POCO as well... Great post

Regards
Marlon
WPF Blog - http://marlongrech.wordpress.com/

[ken...@internode.on.net]

Thanks for the feedback, guys.

@Corrado: Great point. I forgot about the auto-marshalling of property
changes. I will add something about that to my post.

@Mike: Thanks, I wasn't aware of Petzold's advocation of DOs for VMs.
I'm not sure why coercion is more compelling in DOs than in POCOs.
When I need to coerce a value I'd just stick the logic in the property
setter, perhaps calling another method if it's complex. Or perhaps
you're referring to being able to have both base and effective values?
Can you elaborate?

@Colin: I concur that DPs are verbose. Moreover, they are disparate.
Trying to work through the logic in a complex VM is a real PITA when
using DOs:

"This property was changed, so I need to check the metadata to see if
it has any coercion or change logic. OK, it does, so I need to go
check out that logic. OK, that logic changes these other
properties...." and so on.

With POCOs I find that the logic is much more centralized and aligned
much more closely with where you'd naturally expect it to be. That
makes both reading and maintaining the VMs a much more pleasant
experience.

I think code generation is somewhat of a bandaid solution in this
case. It reduces a lot of the typing, but you still have the locality
problem. You'd have to look in both your code generation input file
and your supplementary source file.

I do wonder whether it would have been better to bake DOs into the BCL/
CLR a little more. They really aren't specific to WPF, but that's the
perception because they live in WPF assemblies/namespaces. If they
were at a lower level, it's not too much of a stretch to imagine
language support for declaring them.

Another possible solution to this is future .NET compilers. My
understanding is that both C# and VB.NET compilers will be managed and
*extensible*. This would allow you to hook in your own parsing logic
to support whatever constructs you like. For example, imagine being
able to do this:

public dprop string MyDependencyProperty
{
coerce
{
return value + ".Foo";
}
changed
{
SomeOtherProperty = value;
}
}

And, of course, you could do a similar thing to support
INotifyPropertyChanged in POCOs:

public notifying string MyProperty
{
get; set;
}

Ah well, we'll see ;)

Thanks again,
Kent

[Peter O'Hanlon]

Great article Kent. I like DependencyObjects, but I just find it so much easier to work with POCOs. I like the look of your library - any timescale on when we can "beta" it?

--
Peter O'Hanlon

[ken...@internode.on.net]

Thanks Peter. The library is called "Truss" and I plan on releasing a
beta sometime in April. I will post a link here first so you guys can
bash on it for a week or so before I release a V1.0.

Best,
Kent

[Peter O'Hanlon]

So, I'll be using Onyx and Truss - possibly taking a diversion into Ocean. I'm feeling an Abbott and Costello sketch coming on here.

--
Peter O'Hanlon

[Laurent Bugnion, GalaSoft [MVP, MCP]]

I used to do VM with DOs but about some time ago I asked this group about
their opinion about that and people made quite a compelling argument for
POCOs. I decided to change my practice to see what I prefer. Since then I
find POCOs the way to go for most cases of VM. DOs and DPs are fantastic for
controls, for sure, but often POCOs allow more flexibility for VMs. I also
like that they feel like "bare metal". Sure it is annoying to have to raise
the events by hand, but with snippets it is pretty much a non existing
problem.

As for coercion, DPs are great for that. I find coercion a bit hard to grasp
when you start with it (I know that many of my ex-colleagues at Siemens had
a really hard time understanding how it works), but the fact that the
original value is preserved and restored automatically is pretty cool. The
marshalling is great too, though one might argue that it is a bit too "black
magic" and that marshalling the values "by hand" brings more clarity to the
code.

Cheers,
Laurent

-----Original Message-----
From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com]
On Behalf Of ken...@internode.on.net
Sent: Friday, March 27, 2009 10:34 AM
To: WPF Disciples

Thanks again,
Kent

No virus found in this incoming message.
Checked by AVG - www.avg.com

Version: 8.0.238 / Virus Database: 270.11.30/2025 - Release Date: 03/26/09
20:05:00

[Mike Brown]

Like I said the VM pattern hadn't taken off yet, his advocacy was more for using DOs as your business/domain objects. When I talk about coercion I mean the built in coercion callback that DPs can take advantage of. Like I said, it helps simplify logic when there is intricate interaction between the properties of your view model. If you think about it...that's what DO's were built for, making a view model of a control.

[Dr. WPF]

Wow!  There's no way I can catch up on all the disciples mail in the last few days... so I'm just weighing in on this one and then marking the rest of them as read.

Great post, as usual, Kent.  I'm pretty sure I've said this before, but I fully concur... unless you have a very solid reason to be a DO, don't.  POCOs are the way to go for 99% of all VM classes (and usually the other 1% too).

That is not to minimize the power of DPs in any way!  (Note that DOs only exist to support DPs and the property engine.)  DPs were simply designed with the framework in mind (hence their inclusion in the framework assemblies).  If you're not in the element tree and/or not a visual, you don't receive a lot of the major benefits of DPs.  In that case, they are just overhead.

I often refer to the property engine in WPF as the "coolness engine".  It enables all the cool stuff like binding, animation, triggers, default values, property invalidation, property inheritance, attached properties, etc.  For controls, user controls, freezables, and other view-specific objects, I almost always use DPs so that I can leverage this coolness.

I developed my WPF snippets for DPs, routed events, and commands (I think most have seen them already, but if not, they're available here) specifically to address Colin's point.  They allow me to minimize syntax errors and other trivialities and they bring uniformity to my code.  If you don't have your own snippets, feel free to try mine.  I'm not trying to self-promote or anything (because unfortunately, I haven't found a way to monetize these... "if only I had a nickel for every..." :-p).  It really is about efficiency and error reduction.

I'm sure T4 templates are great too, but I like having DP declarations inline so I can quickly see them when necessary.  Since my DPs are wrapped in #region..#endregion blocks, they can be collapsed most of the time but still accessible for tweaking when necessary (without worrying about what the next codegen pass will do).  Still, if anyone builds a set of T4 WPF templates, I'd be willing to give them a try.

Wrt auto-marshalling property changes, I'm not a huge fan but I understand why they did it.  Solving an issue under the covers (which people tend to perceive as black magic cuz they don't take the time to look at what is really happening) is not always the best approach... especially if that voodoo only works in certain circumstances (e.g., supports background changes to bound properties but not bound collections).

Lots else to comment on... but not enough time.  I'll just side with all the smart people.  You know who you are.  ;-)

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

[Sacha Barber]

Quoting the Doc "I'll just side with all the smart people.  You know who you are.  ;-)"

I think that would be you Doc

---

Date: Fri, 27 Mar 2009 18:26:38 -0500
From: a...@drwpf.com
To: wpf-di...@googlegroups.com; colin.e...@gmail.com
CC: wpf-di...@googlegroups.com

Subject: [WPF Disciples] Re: View Models: POCOs versus DependencyObjects

---

Windows Live just got better. Find out more!