Why DependencyObject of WPF and WF are different? | Tech Off

ido.ran

Really, this is so bad design.

It force developer to choose one implementation and by doing so make it's object incompatible with the other framework.

It the two DependencyObject are really different, give them different names (I know they are in different namespace) because beside the namespace they look very much the same.

If they are the same, just developed in parallel and were not merged, then this is just bad practice.

Any fix to WPF DependencyObject will have to be duplicated to WF and vice versa.

What do you think?

PerfectPhase
"This is not war, this is pest control!" - Dalek to Cyberman

Looks like WF v4 is a near complete re-write, be intreasting to see if they've fixed this.

stevo_
Human after all

I think it was designed in the WPF space and then 'inherited' in WF.. they didn't want a dependency on having WPF assemblies so they 'cloned' it.. but yes the dependency system is pretty generic and should probably be part of something more like the system component model..

vesuvius
Das Glasperlenspiel

Answer is available at http://blogs.msdn.com/kcwalina/archive/2008/04/25/MEF.aspx.

I would also higly recommend the Brad and Krys PDC video on framework design. Most people do a bit of framework and application design, but the guys in charge of the BCL have some valuable insight.

ido.ran

In reply to vesuvius

#Dec 5th, 2008 @ 12:32 AM

Hi, MEF looks great, but it has nothing to do with DependencyObject.

I agree that talking to BCL designers is the best, do you know where to find them?

Ido.

vesuvius
Das Glasperlenspiel

In reply to ido.ran

#Dec 5th, 2008 @ 8:40 AM

Yes the main post is about MEF, but if you read the second paragraph;

The BCL team did a good job fulfilling the role of the team responsible for decreasing duplication and providing common abstractions for the low levels of the platform. Unfortunately, we did not have a similar team really focused on these sets of issues higher up on the stack. This resulted in some unfortunate duplication (like several data binding models for each of the application models, different dependency property system for WPF and WF) and lack of common abstractions (what undo APIs should my generic application plugin call?) for application model code. The Application Framework Core team is now in place to start addressing the problems.

You will see that the re-write suggested by PerfectPhase appears to be what is/has happened/happening.