Jun 20, 2010 at 5:48 PM
Edited Jun 20, 2010 at 6:13 PM
I understand your concern. I have searched for ways of keeping the Model pure, and I continue to do so. Perhaps the following observations will help.
"Independent" is not a UI concern
Dependency among values in a program is a general concern. It manifests most visibly in the user interface, but it is important to all aspects of the system. Other examples include caching and synchronization, both of which are supported by Update Controls.
It is natural for the Model to participate in dependency management.
The Independent type is defined in the core assembly UpdateControls.dll. All of the WPF specific stuff is in UpdateControls.XAML.dll, an all of the Windows Forms stuff is in UpdateControls.Forms.dll. So even though the model knows about Update Controls,
it does not know which UI platform (if any) you are using. (BTW, this is not true for the Silverlight assembly, since the runtime and the UI platform are already tightly coupled.)
At its core, Update Controls (despite the name) is a dependency management library, not a UI library.
The Model would otherwise implement INotifyPropertyChanged
All of the code that Microsoft tools would have you generate (Entity Framework, Linq to SQL, RIA Services, etc) implements INotifyPropertyChanged. For the same reason that Independent is not UI centric, niether is INPC. It can be used for any dependency
management. But if you take offense to the Model using Independent, you should also take offense to the Model implementing INPC.
The difference, of course, is that INPC is part of the .NET framework, while Independent is part of a third-party library. That is why I chose a liberal open source license - so you can understand and trust a component that you take such a deep dependency
Eventually, dependency management will be part of the platform
As you pointed out, it would be better if the Independent type were not explicit, but rather an implicit behavior of the compiler. I don't yet have the hooks to make that happen. Eventually, I will.
The march of technology has two phases: libraries and platforms. First, ideas are implemented in libraries. Then, once the idea has sufficiently baked in that crucible, it is cemented into platforms. Dependency management is still very much in the first
Aspect oriented frameworks give us some limited capability to inject cross-cutting concerns into our systems. Dependency management could be implemented as such a cross cutting concern. But if I were to choose one of those frameworks, you would have a much
bigger code dependency to justify. I prefer to remain on the sidelines until the majority of the community decides to adopt AoP.
Anders has stated that "compiler as a service" is on the .NET roadmap. Once that happens, we should be able to install add-ins to the compiler. Then I'll be able to inject dependency management during compilation.
I am working in that direction
To the degree that the platform allows, I have done some work in the direction of pre-compilation. I've defined a
T4 template for Linq to SQL, and I'm actively working on a
modeling language that solves the dependency management and synchronization problems. These both implicitly add dependency management constructs during code generation.
Your contributions are welcome
This is an open source project. Please peruse the source code to see how Independent works. If you can find a solution that satisfies your requirements better, please share your change with us.