Develop Reference

When to use ObservableCollection vs AdvisableCollection w/ PostSharp NotifyPropertyChanged?

Here is the PostSharp support discussion (titled: "NotifyPropertyChanged and ObservableCollection") that sparked my initial confusion on this topic. Further explanation is in the answer I posted (not 100% confident in my answer).
I'm a little confused on how PostSharp's [NotifyPropertyChanged] aspect affects a class's collection properties (if at all), and whether I need to be using an ObservableCollection<> or AdvisableCollection<>. If I understand correctly, if I want notifications from the collection, I MUST change it to at least an ObservableCollection<>, correct? The [NotifyPropertyChanged] aspect doesn't magically make whatever collection types are in the class observable.
If that's the case, then when would I use ObservableCollection<> or AdvisableCollection<>? Should AdvisableCollection<> be reserved for when I need the aggregation pattern applied by PostSharp? Or should I just always use AdvisableCollection<> whenever applying PostSharp's [NotifyPropertyChanged] attribute?
[NotifyPropertyChanged]
public class Test {
public int PropVal { get; set; }
public List<string> PropCollection { get; set; } //Should this be ObservableCollection
//or AdvisableCollection?
}

Congratulations on the Tumbleweed badge and many apologies for the delayed answer.
Collections are currently not well integrated with the aspect in sense that there is a bit of work needed for real-life examples to work properly. Let me explain few key steps:
[AggregateAllChanges] instructs the runtime that it should relay any change observed on the collection as a change of the property itself. This in particular means that a virtual Item[] dependency is created (which is used by a "standard" collections to notify change of collection shallow "state").
In reality properties working with collections content are usually aggregates in some sense, depending not only on set of items stored in the collection but also on state of individual objects in the collection. Currently there is no way to express that and/or selectively relay these changes. For this you need to create a class derived from ObservableCollection<T> that looks like following:
[NotifyPropertyChanged]
public class ObservableCollectionEx<T> : ObservableCollection<T>
{
protected override void OnCollectionChanged(NotifyCollectionChangedEventArgs e)
{
if (e.Action == NotifyCollectionChangedAction.Remove)
{
foreach (T item in e.OldItems)
{
((INotifyPropertyChanged)item).PropertyChanged -= OnItemPropertyChanged;
}
}
else if (e.Action == NotifyCollectionChangedAction.Add)
{
foreach (T item in e.NewItems)
{
((INotifyPropertyChanged)item).PropertyChanged += OnItemPropertyChanged;
}
}
base.OnCollectionChanged(e);
}
protected void OnPropertyChanged(string propertyName)
{
base.OnPropertyChanged(new PropertyChangedEventArgs(propertyName));
}
protected void OnItemPropertyChanged(object sender, PropertyChangedEventArgs e)
{
NotifyPropertyChangedServices.SignalPropertyChanged(this, "Item[]");
NotifyCollectionChangedEventArgs collectionChangedEventArgs = new NotifyCollectionChangedEventArgs(NotifyCollectionChangedAction.Reset);
base.OnCollectionChanged(collectionChangedEventArgs);
}
}
The above does exactly what is needed - when anything changes on any object within the collection, collection reports that it itself had changed.
Now in a class it would look like this:
[NotifyPropertyChanged]
public class TestClass
{
[AggregateAllChanges]
public ObservableCollectionEx<TestItem> Items { get; } = new ObservableCollectionEx<TestItem>();
[SafeForDependencyAnalysis]
public int Sum
{
get
{
if (Depends.Guard)
{
Depends.On(this.Items);
}
return this.Items.Sum(x => x.Value);
}
}
}
[NotifyPropertyChanged]
public class TestItem
{
public int Value { get; set; }
}
The above is not ideal performance-wise if there are other properties on the TestItem class that are frequently changed. In that case, one may consider to add a some kind of filtering to ObservableCollectionEx.
Regarding AdvisableCollection<T> you are right - while it can be used, it's main purpose is different.

Well, after receiving the "Tumbleweed" badge on this question (not intended, but funny... better than downvotes), I've spent some more time trying to sort out/better define my confusion and coalesce my own answer from the chaos...
The PostSharp support discussion (titled: "NotifyPropertyChanged and ObservableCollection") that sparked my initial confusion mentions two things:
-Support for intercepting changes in ObservableCollection<> was added in 4.2.
-To raise the PropertyChanged event on each collection change, the collection must be marked with [AggregateAllChanges].
So it would seem PostSharp's NotifyPropertyChanged aspect supports at least ObservableCollection<> if the [AggregateAllChanges] attribute is applied. However, a subsequent conversation on the PostSharp site's chat feature yielded:
-"You need to use collection classes defined by PostSharp to have reliable support for NotifyPropertyChanged aspect. See Working With Collections" (which mentions the Aggregatable pattern).
-After reading the provided documentation, the conclusion seems to be that I need to use AdvisableCollection<> (a PostSharp-defined collection) instead, but the examples all seem to be in the context of the Aggregatable pattern, with parent-child relationships, etc. Hence my confusion. I'm not trying to set up parent-child relationships, just trying to get NotifyPropertyChange on collections.
Next is another support discussion that demonstrates using NotifyPropertyChanged with a non-PostSharp-defined collection, applying [AggregateAllChanges] to a BindingList<>.
-In this instance, BindingList<> did not have one of the events that NotifyPropertyChanged expected, so this had to be wired up manually with NotifyPropertyChangedServices.
For a bit more background, I read this PostSharp blog post that gets into the Aggregation and Composition patterns.
Trying to boil everything down, my (possibly incorrect) conclusion is:
-[AggregateAllChanges] applied to non-PostSharp-defined collections (ObservableCollection<>, BindingList<>) is effectively an opt-in to the NotifyPropertyChanged aspect, with the caveat that the collection you apply it to (ex. BindingList<>) may not support all of the events the aspect expects, requiring you to wire up the PropertyChanged notification yourself via NotifyPropertyChangedServices.
-AdvisableCollection<> implements INotifyPropertyChanged as well as INotifyCollectionChanged (as does ObservableCollection<>), can be used in place of standard .net collections (not BindingList<> though... different interfaces), and would still require [AggregateAllChanges] to raise PropertyChanged notifications. Otherwise, the purpose of AdvisableCollection<> is to allow injection of behaviors related to the Aggregatable pattern.
If anyone has corrections to these assumptions, please feel free :) I will gladly mark a clearer/better explanation as the answer.

Model not implementing INotifyPropertyChanged

In the context of the MVVM pattern, how would one structure the ViewModel when Models do not implement the INotifyPropertyChanged interface?
I like to keep my Models as simple as possibile and implementing the INotifyPropertyChanged interface only for binding purposes seems like unwanted complexity. That's why most of the times i require my VMs to wrap model properties like in the following example:
class ViewModel : INotifyPropertyChanged
{
private Model model;
public int MyProperty
{
get { return model.MyProperty; }
set
{
if (value != model.MyProperty)
{
model.MyProperty = value;
// Trigger the PropertyChanged event
OnPropertyChanged("MyProperty");
}
}
}
/* ... */
}
This will make bindings work ok, including two-way ones.
Now, what would happen if a command executes a model method with complex logic (affecting the value of many properties of different objects)? The model is not implementing INotifyPropertyChanged so there's no way we can know it was updated. The only solution that comes to my mind is to use messaging (mediator pattern) to inform all VMs of the execution of the method so that each VM fires the PropertyChanged event for each potentially affected property:
// Sample ICommand.Execute() implementation
public void Execute(object parameter)
{
var model = (Model)parameter;
model.VeryComplexMethod();
// Just an example, the string "VeryComplexMethodExecuted" is
// sent to all listening VMs. Those VMs will in turn fire the
// PropertyChanged event for each property that may have changed
// due to the execution of the complex model method.
Messaging.Broadcast("VeryComplexMethodExecuted");
}
Please share your ideas, thanks.

Declare your members virtual and use something like Castle Dynamic Proxy to inject change notification automatically:
http://ayende.com/blog/4106/nhibernate-inotifypropertychanged
This has to be used with care when your models are being created in your data layer because it returns a new instance entirely. Your database code will think the object has changed and serialize it back out again which will in turn have a huge impact on performance. Fortunately all the good ORMs provide mechanisms for you to substitute in class wrappers at creation time.

Getting lookup view model to trigger Modal Dialog

What's the right way to get my viewmodel to trigger a custom lookup control to throw up a modal dialog that essentially represents that lookup viewmodel? The custom lookup control's data context is that of the parent record view model. The lookup control also has another DependencyProperty that has it bound to a lookupviewmodel property on the parent record view model and this represents a sub lookupviewmodel.
METHOD 1) I currrently use an event on the lookupviewmodel that the custom control knows to listen for.
METHOD 2) I tried throwing a validation exception within the setter of the property on the lookupviewmodel that the lookup control's text propery is bound too. Then I hooked the ErrorEvent in the custom lookup control. But it seems that if the user "corrects" the value from within the dialog while in this event, the original value sticks. And worse, even after I call Validation.ClearInvalid, another ErrorEvent still fires that somehow adds the error back. So everything works here in the sense that all the viewmodels have the correct data, it's just that it seems like the textbox is ignoring that the bound text property has changed on the underlying data source when inside an ErrorEvent. So it seems like I can't correct an error while inside the processing of that error?
Another sub issue within method 2 is that Validation.ClearInvalid doesn't remove the red error border. I had to manually clear the ErrorTemplate too. Is that right?
I'd like to find a way to use natural error handling within the control to get it to throw up the modal dialog.

This isn't what you use events for. Events exist to facilitate decoupling: the object raising the event shouldn't know or care what the object(s) listening to it are doing. You're expecting an event to be able to change the value of a property from inside the property's setter - or worse, your event handler is calling the very property setter that's raising the event that it's handling, which means that you have to do something pretty hackish to avoid a stack overflow.
Your description isn't very clear (you're describing both the problem you're having and the non-working solutions you're trying at the same time, which is confusing), but it sounds like what you're trying to do is something more like:
if (IsValid(value))
{
_Property = value;
}
else
{
_Property = GetValueFromDialog();
}
The problem is that you don't want to have code in your view model that throws up a dialog, since that creates a view model that can't be tested outside of your WPF application.
The answer in this case is to use dependency injection. Create an interface called IDialogService:
interface IDialogService
{
object GetValueFromDialog();
}
Now add this property to your view model:
public IDialogService DialogService { get; set; }
The above code becomes:
if (IsValid(value))
{
_Property = value;
}
else
{
_Property = DialogService.GetValueFromDialog();
}
Create a dialog service for use in your WPF application that actually throws up the dialog and gets the result. When you instantiate your view model in your application, do this:
MyViewModel vm = new MyViewModel { DialogService = new WpfDialogService(); }
Thus, in your application, the property setter will put up the dialog and get the result exactly as you expect it to.
For your unit tests, create a mock dialog that looks like this:
public class MockDialogService : IDialogService
{
private object Result;
public MockDialogService(object result)
{
Result = result;
}
public object GetValueFromDialog() { return Result; }
}
You can then write a test like:
MyViewModel vm = new MyViewModel { DialogService = MockDialogService(ExpectedResult) };
vm.Property = InvalidValue;
Assert.AreEqual(ExpectedResult, vm.Property);
The above is really more a sketch of a solution than a solution - depending on how your application uses dialogs, you may need a lot more features than what are sketched out here. If you take a look at MVVM frameworks you'll find that a lot of them implement dialog services of one kind or another.

You can use a framework like MVVMLight or Prism which allow you to pass payloads between different entities in totally decoupled ways. MVVMLight is very lightweight compared to Prism. It has a concept of Messanger which acts as a system wide event bus. Similarly you have EventAggregator in Prism.

Extending a solution for simple binding to a 'Text property to multiple Controls to handle binding to any Type?

My question is : how to move beyond writing a custom implementation of a technique for databinding multiple controls (controls without built-in DataSource properties), for each possible type of data, to simple properties ... as described and demonstrated in code that follows ... to achieve a more poweful solution that will be independent of whether the binding is to a string, or an int, or other types.
My guess is: this will involve reflection; but, I'm stuck at that point. I'm looking for strategic advice on which "direction" to move next, hints, clues, not a complete code answer, but of course I appreciate all responses, and I'll sure study code if you post code in reply ! Marc Clifton's 2005 article on CodeProject Simple Databinding: appears to demonstrate a reflection based approach: but, honestly, I do not really grok his code, and, in terms of .NET, 2005 is a long time ago.
Background: Partly in response to various SO questions and answers, like: Update Usercontrol on Three Forms: I've evolved a successful technique for databinding text properties of various controls simultaneously to one source defined in a Public class; also been able to "abstract" some of the details of the binding process using a static class that defines one extension method, and two public methods.
I've verifed that TextBoxes on Controls in a "MainForm," TextBoxes on a UserControl on the MainForm, and a TextBox on a second Form opened "independently" (i.e., form2.Parent == null) all update properly (i.e., two-way binding is in effect) from the "DataSource equivalent" public class. Change one: change all.
Code: an instance of this class will supply the target property (theText) for databinding:
public class TextDataBinder
{
public event PropertyChangedEventHandler PropertyChanged;
private string _theText;
public string theText
{
get { return _theText; }
// note : if 'setter is declared 'internal : blocks
// auto-updating when run-time user modifies consumers
// but will still allow update via code
set
{
_theText = value;
OnPropertyChanged(new PropertyChangedEventArgs("theText"));
}
}
protected void OnPropertyChanged(PropertyChangedEventArgs e)
{
if (this.PropertyChanged != null)
{
this.PropertyChanged(this, e);
}
}
}
Code: this static class enables hiding some of the binding process complexity, and allows easy binding to multiple controls:
public static class TextBindingExtender
{
public static TextDataBinder CurrentDataSource;
public static void SetCurrentDataSource(TextDataBinder newCurrentDataSource)
{
CurrentDataSource = newCurrentDataSource;
}
// extension method for Control
public static void AddTextBinding(this Control theControl, string controlPropertyName, string targetPropertyName)
{
theControl.DataBindings.Add(controlPropertyName, CurrentDataSource, targetPropertyName, false, DataSourceUpdateMode.OnPropertyChanged);
}
// bind to all Controls in a List<Control>
public static void AddTextBindings(List<Control> theControls, string controlPropertyName, string targetPropertyName)
{
foreach (Control theControl in theControls)
{
theControl.AddTextBinding(controlPropertyName, targetPropertyName);
}
}
}
How the above classes are used (in a Form Load event) :
// create a new TextDataBinder
TextBindingExtender.CurrentDataSource = new TextDataBinder();
// bind to multiple textboxes, label, on a UserControl, on another Form, etc.
TextBindingExtender.AddTextBindings(new List<Control> { textBox1, textBox2, userControl11.tb, label1, instanceOfForm2.tb }, "Text", "theText");
// test assigning some initial text to the bound property
TextBindingExtender.CurrentDataSource.theText = "some initial text";

It really depends what you want to do; but ultimately common data-binding (for simple properties, done manually) consists of:
obtaining a property; preferably via TypeDescriptor.GetProperties(obj)[propName], giving you an abstraction (PropertyDescriptor)
asking the property if it is read-only (.IsReadOnly)
obtain (or set) the value (.GetValue(), .SetValue())
asking it for a converter to format / parse the value (.Converter, .ConvertFromString(), .ConvertToString()) THIS is a key bit that means you don't have to worry about what the data type is
asking it for the caption (.DisplayName, or .Name if that it empty/null)
asking it if it supports property-specific notification (.SupportsChangeEvents)
asking it to add/remove a change handler (.AddValueChanged(), .RemoveValueChanged())
you might also want to look at whether the object supports centralised notification (look for INotifyPropertyChanged)
If you might be binding to a list rather than a single object:
- the list might be abstracted behind IListSource
- the list might have custom properties, so check for ITypedList
- otherwise, identify the Type of the items and use TypeDescriptor.GetProperties(type)
- you need to consider a "currency manager" (i.e. should all the things bound to the same list be pointing to the same record in the list all the time)
There are also things like ICustomTypeDescriptor and TypeDescriptionProvider to consider, but most of the time TypeDescriptor handles this for you automatically.
As you can see - lots of things to think about! Lots of work... the one thing that you don't have to do is reflection; this is abstracted behind PropertyDescriptor. The reason for this is that not all data is static-typed; think about DataTable - the columns (which map to bindable data properties) are not fixed at compile-time, so reflection isn't appropriate. Likewise, some other types have custom "property bag" implementations. PropertyDescriptor lets your code handle either dynamic (not in the 4.0 sense) and reflective properties identically. It also works nicely with things like "HyperDescriptor", another property customisation.

Castle.DynamicProxy2 and Adding a Property at Run Time

I am using Castle.DynamicProxy2 and I am instantiating my proxy as such:
private static T GenerateProxy()
{
ArrayList addtlInterfaces = new ArrayList();
addtlInterfaces.Add(typeof (INotifyPropertyChanged));
addtlInterfaces.Add(typeof (EntityStatus));
object entityProxy = ProxyGenerator.CreateClassProxy(typeof(T),
addtlInterfaces.ToArray(typeof(Type)) as Type[],
ProxyGenerationOptions.Default,
new IInterceptor[] { new LazyInterceptor() });
return (T)entityProxy;
}
My interface of IEntityStatus looks like such:
public interface IEntityStatus
{
bool IsDirty
{ get; set;}
}
I need to be able to use that property during run time so that when my DTO has a property changed event the event could set the DTO to dirty. However because it is an interface and has no explicit implementation I am at a loss as to how to do this. Creating a delegate for the get and set method is an option I would like to avoid. So is there another way to achieve what I am looking to achieve?
I realize I could set up a collection of all my active DTOs and when the property changed event fires on one of the DTOs I could update that collection to show that this particular DTO is dirty, but I would really like for this information to be a part of the proxied DTO for pure syntactic ease.
Look forward to responses!

I dont know how you handle the INotifyPropertyChanged but I'd use mixin for both interfaces, having one subscribed to another's event. Is that a viable solution?