This project is read-only.

A way to do this without dicking with Model?

Jun 20, 2010 at 3:03 PM

I'm all in favor of dirtying up the ViewModel, but putting API specific code into a Model isn't clean at all, and counter to what you try to keep the model as. Is there no way to map the properties of the Model to the Independent type without the Model being aware of it, at least before compilation?

Jun 20, 2010 at 6:48 PM
Edited Jun 20, 2010 at 7: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 upon.

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 phase.

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.