Talk Nerdy To Me

Okay, so I blogged about how C# BindingList<T> serialization is broken and how to fix it. The problem centers around filling a BindingList subtype with items that implement INotifyPropertyChanged. This enables your list to fire ListChanged events indicating ItemChanged whenever a property of a list item changes. Unfortunately, serializing and deserializing the list causes the ItemChanged notification to stop firing unless you take steps to properly rebuild the list. This happens because C# event handlers aren’t serializable, and .NET fails to rewire the listeners.

A colleague of mine asked for a quick example to demonstrate the problem, so I whipped up this test case.

Read the rest of this entry »

When you move from one programming language to another, do you eventually find yourself thinking differently?

After eight years of slinging Java code, I converted over to C#. The C# language borrows (steals?) heavily from Java, but it also has added some features. Some of C#’s most valuable introductions to the language have now been adopted by Java. Things like attributes, generics, and auto-boxing - which first appeared in C# - have now been added to the JDK as of 1.5. It’s only a matter of time until Java adopts using-blocks and the yield keyword, too.

Despite this back-and-forth trading of features and enhancements, each language still maintains its distinct flavor. Some facets of each language - many of which are quite subtle - will probably never be adopted by the other simply because their introduction would create such a fundamental shift in language concepts it would invalidate a lot of prior work.

So, I was careful about my approach to C#. My Java work had been preceded by seven years of C++, and I remember what that transition was like. Although Java is strikingly similar to C++, the similarities are deceiving. Seemingly minor differences between the two languages created a sea change in how I thought, how I designed code, and how I tested applications.

Read the rest of this entry »

I previously blogged about how to use the C# INotifyPropertyChanged interface with BindingList<T> instances so that your lists properly fire the ListChanged event with a ListChangedType of ItemChanged.

In that post, I also alluded to the fact that BindingList<T> is flawed with regard to serialization of BindingList<T> subtypes. The problem has to do with the fact that BindingList<T> listens for PropertyChanged events on any of its list items that implement INotifyPropertyChanged. However, because event handlers are not serializable, those listener connections are lost during the serialization process for subtypes, and they don’t get rewired when the list is deserialized. It’s straightforward to do that, but the implementation is missing from the .NET SDK, so we have to write it ourselves.

Read the rest of this entry »

After reading Bil Simser’s discussion on DataTable vs. BindingList<T>, I’m convinced that BindingList<T> is the way to go for representing domain objects in C#. However, effective use of BindingList does require a certain amount of planning and forethought on the part of the developer. There are a number of things you can do to increase your chances of success with BindingList, but this post is about having your list items implement INotifyPropertyChanged in order to propagate change events through the BindingList itself.

Read the rest of this entry »

In software development, experience matters. A former boss of mine used to say “Good judgment comes from experience. Experience is the result of a lot of bad judgment.” Most of my sense of “the right way” to do things has been formed by first doing it in every conceivable wrong way.

In our rapidly changing field, there are seldom “textbook solutions” to problems. The textbooks are out of date shortly after they go to press! Thus, we defend our technical decisions - be it object modeling or database design - by pointing out the flaws in the alternatives. We become aware of these flaws by reflecting on past experiences with the same problem. A successful solution to the problem then produces a design pattern, and a proven design pattern applied to future projects allows us avoid prior mistakes.

That’s perfectly reasonable - mostly. Unfortunately, that can lead to a trap when we forget the original problem behind our so-called “best practice” solution.

Read the rest of this entry »