Greetings,
This is probably a question specifically for Rocky regarding CSLA. We've recently encountered an issue with memory leaks, and they were related to this specific Microsoft Article:
http://support.microsoft.com/kb/938416
Anytime you Bind to a BusinessListBase.SomeProperty in WPF, there is a potential for a memory leak because CSLA’s BusinessListBase does not implement Property Changed events.
For example, we have had issues with binding to SomeList.Count, to hide/show UI components based on whether or not the list has any data. This can result in substantial memory leaks, especially if you have a large object graph and any one of your objects gets bound in this manner. WPF will try to attach its own events, which can root the entire object in memory.
So, i'm mostly curious - was there *good reason* not to implement INotifyPropertyChanged on the BusinessListBase? Because even the "ReadOnlyBase" has this implemented, and given that it's read-only, it should never change, right?
We're thinking of just implementing this in our subclass but I want to make sure there wasn't some specific reason not to do this before we get to crazy.
Thanks in advance,
GS
BusinessListBase is a list, and it derives from BindingList<T>.
In CSLA 4 it derives from ObservableCollection<T> - which is more WPF friendly.
So CSLA doesn't implement the Count property - Microsoft does that in the base classes.
And, fwiw, ObservableCollection<T> doesn't implement INotifyPropertyChanged either - so their WPF-oriented collection base class apparently violates their own recommendation based on that article.
The short answer though - is that prior to XAML it wasn't valid to bind to properties on a list/collection. Windows Forms doesn't have a provision for doing such a thing. So a collection type would never implement INotifyPropertyChanged, because nothing would listen for it. Implementing it would be silly.
Clearly XAML changes the rules - but even in .NET 4 ObservableCollection<T> doesn't implement INPC - so clearly Microsoft doesn't consider that an important or desirable scenario to address.
Fwiw, you can't solve this in a subclass. You'll need to start with something that inherits from System.Object and implement all the collection interfaces by hand. Have fun - I've done that and it is an interesting challenge!
Thanks Rocky for the swift response and insight -
It sounds like CSLA 4 may resolve the issue, because looking over the ObservableCollection on MSDN, it appears that Microsoft does implement INotifyPropertyChanged.
http://msdn.microsoft.com/en-us/library/ms668604.aspx
public class ObservableCollection<T> : Collection<T>,
INotifyCollectionChanged, INotifyPropertyChanged
The memory-leak article reads like stereo instructions for sure. It's not the .Count that is a problem, its any property that could be bound on an object that doesn't implement the interface that can cause an issue. The root problem is that Microsoft wires up the events automatically by creating a property descriptor that gets stored in a static hash-table. I know this isn't CSLA's problem, it seems clearly like an oversight on Microsoft's part, yet gets described as "by design".
Anyway, I realize that binding to a property of a list seems silly, but when WPF lets you do crazy things and bind to whatever you want - and a common school of thought is to "do everything in WPF instead with no code-behind", it sure makes it simple to get leaky, real quick.
Thanks again for the added insight!
GS
Anyway, I realize that binding to a property of a list seems silly, but when WPF lets you do crazy things and bind to whatever you want - and a common school of thought is to "do everything in WPF instead with no code-behind", it sure makes it simple to get leaky, real quick.
I think that's the key - XAML changed the rules - it is no longer silly to think about these things, because they are now meaningful and valuable.
Copyright (c) Marimer LLC