For some reason, when someone is designing software at any layer forgets about checking the stack of available classes for re-using purposes.  Text/Value UI-Controls still exist because they offer a simple way to show information (i.e. ListBox, DropDownList and so on).

Over the years (and over lines of code) I always find myself reading code with any of these common solutions when binding data to Text/Value UI-controls:

  1. Binding against any general-purpose (and thus record like) data type.
  2. Binding against custom domain-related data types.
  3. Binding against specific/self created key-value data types.

Let me explain a bit more each of the above solutions I have found with a movie store application example in which one you have a database with records about movies and you want to bind the data against a ListBox.

In the first solution you have a method to load the table records into a general record class like the System.Data.DataRow and then elsewhere the collection is binded against the UI-control.

In the second solution imagine anywhere in the source code exists a “Movie” class, with attributes like “Author” or “Director”. In this solution the whole Movie object is bubbled up layers and finally binded against the UI-control.

In the third solution the experienced developer learns that over different projects the same scenario appears over and over, so cleverly develops a custom data type with Text and Value attributes.

Maybe you’ve written this kind of code but don’t worry because all of us had done the same for at least once. The common problem with all solutions is that they don’t meet the Leanness purpose, which stands for having only the necessary or simply put, “having little body fat”. In all cases more attributes/methods than those required/needed are passed through layers.

There are also specific problems with each one: in the first solution little or no abstraction exists, in the second you are forcing an abstraction for multiple/unrelated purposes and the third usually ends up full of specific attributes/methods for specific products.

So what’s the best solution? There is no best solution. A triage must be done instead. A good solution could be reusing the ListItemCollection class or designing presentation entities (don’t be afraid of writing UI-layer scope classes if you need special UI-processing).

Cheers,

Javier Andrés Cáceres Alvis

Microsoft Most Valuable Professional – MVP
Intel Black Belt Software Developer