I'm using .NET with Windows Forms, but I believe there may be similar concerns with other toolkits.Suppose we have a list of objects of a certain type. Using an example to make the following easier to read, suppose there is a Category class to represent them. We display a list of them to allow a user to filter articles by category. Binding the ListBox component to a data source of Category objects is a way to do so.What would be the best way to add an entry labelled All in the same ListBox? Assume that it has to be in the list, and not as a separate option like a radio button.I can think of the following approaches, but all of them seem to have a drawback.Create a dummy Category instance named All and an invalid ID.This is the easiest way but it feels wrong conceptually, as All is not actually a category (no article belongs to a category named that). Also, depending on the framework the UI may not be allowed to create Category objects.Don't use data binding at all; populate the list box with strings and use the selection's index to get the object from the data source.This may beat the point of having data bound controls, and adds potential problems: What if we also want to add a None entry in the future? We'll have to increment the list box's selected index by 2 instead of 1 to get the correct object from the data source.Use an intermediate class, CategoryListItem, to populate the list box with. It has a reference/pointer to a Category which is null for dummy entries.This one may be more elegant, but it adds the overhead of creating a new list of CategoryListItem instances for every list of Category instances we want to display.Is one of the above a recommended way to data bind to such a component, or perhaps a way I haven't thought of?
Best practise for databinding when a non-data object is included with the data
programming practices;.net;data;binding;view
Normally, a single-selection listbox offers a list-of-values interface for setting up, and a single-value interface for querying its state. You give it a list of values to present, and it tells you which one of them is selected. (Regardless of whether it is always-open or drop-down.) It is the same as a group-of-radio buttons: only one of the radio buttons may have a bullet in it at any given time.What you want instead, is a control which again offers a list-of-values interface for setting up, but a set-of-values interface for querying its state. The range of possible values is again fixed, but you may select as many of them as you want, including none of them, or all of them. So, clearly, this control is backed by a Set data type. The kind of control which is normally used for that sort of thing is a group of checkboxes, or a listbox with checkmarks, or, in the old days, a multi-selection listbox.  (That was before they realized that users can't be bothered with holding down the Ctrl key while clicking with the mouse.)Now, for some reason you have decided to use a regular listbox for this job, which means that you do not care to give your user the ability to select two categories at the same time, all you want them to be able to do is select either one category, or all categories. (And perhaps no categories in the future.)  That's fine, as long as you realize that this choice of yours should only affect the appearance and the user experience that the control offers to the user, it should not affect the interfaces that the control provides to your application. From your application's point of view, this control should still implement a list-of-values interface for setting up, and a set-of-values interface for querying its value.  The question of whether it will contain a checkbox next to each choice, or special select all and select none entries, should be of absolutely no concern to your application.  It should be possible for you to replace it in the future with a group of checkboxes, without altering the way your application interacts with it.So, what I would do if I was in your shoes is that I would sublcass the existing listbox control, (or I would create an entirely new control which aggregates the existing control, I do not remember right now which approach is recommended in WinForms,) to create a new multi-selection-listbox control which looks like a list, but offers a set-of-values interface for querying its value.I would have the new control add to itself the one or two extra pseudo-items needed so that it can easily select all of its contents, or none of its contents.  That would most closely correspond to option #1 above, but it is irrelevant, because this approach is a lot more than doing option #1.  Note how, when describing this control, we are now talking about items and not categories: this is a general purpose control which can be used for anything you can think of besides categories: reusable, and also replaceable with something better if the need arises in the future.The point behind my recommendation is to avoid ruining your application logic with fine-grained user interaction considerations.  Keep things separate, and let the user experience be the sole responsibility of the GUI controls themselves. Let it be their problem. GUI controls should abstract the way they work behind nice, clean, and minimalistic interfaces that correspond to simple abstract data types, and the application logic should only have to interact with these abstract data type interfaces.