Hi Michael-- Really intruiging library. I like what it does, but I've got a hurdle to jump before I can use it. Here it is: I build applications around domain models, generally following Domain-Driven-Design principles. I'm sure you already know where I'm
going with this, but for the benefit of anyone reading this who might not, please bear with me while I elaborate.
One of the key rules of DDD is that you keep your domain objects focused only on their role in the domain, which requires that you keep them independent of all infrastructure concerns. A domain model should not know or care how it is persisted
or displayed. As I understand UpdateControls, the sentry code needs to go in data objects, whereas presentation objects are clean POCOs. From a DDD perspective, that appears to violate separation of concerns for a domain model, since it adds
presentation-related logic into the model. In other words, if I ever change my UI technology, I will need to reopen my domain model and rip out all the sentry code.
DDD often uses wrapper classes to adapt domain classes for display, and right now that's what I do, using MVVM. That way, if I ever change my display technology, I don't have to touch my domain classes; I simply toss out the adapters and write whatever adapters
are needed for the new technology.
And that brings me to my question: Can UpdateControls be adapted so that the sentry code goes into the view (presentation) model, rather than the domain model? That way, the domain model remains clean POCOs. Thanks for your help.
Aug 10, 2009 at 4:38 AM
I understand your concern. But I don't think that moving the Independent sentries to the view model is the correct answer.
Despite its name, Update Controls is not really a UI library. It's a dependency library. It's all about the relationship between dependent data and independent data. Dependent data
could be a UI, but it could also be a cache, or a service result, or a signal to an external system.
Update Controls has three assemblies, two of which are UI specific. UpdateControls.XAML.dll connects dependent data to WPF DependencyProperties. UpdateControls.Forms.dll connects dependent data to Winforms controls.
But the third assembly -- UpdateControls.dll -- just has the core classes Dependent and Independent. It has no UI concerns. Your domain assembly could take a dependency upon UpdateControls.dll without poluting itself with UI code.
If you feel comfortable with implementing the Observer pattern in your domain model (wheter INotifyPropertyChanged or your own interface), then you can also feel at ease putting Independent sentries in your domain model. Just like the Observer pattern, Update
Controls is designed to decouple the observer (dependent) from the subject (independent).