While designing software you think about the system in abstract terms and you try to model under the Object Oriented paradigm, so your universe looks like a harmonic set of objects, which usually are persistent as tables (the relationship between objects and tables is usually 1:1). You’re happy, the design seems perfect.

In the middle of development a software developer start using the “new UI control” that seemed to be the best in the research stage and quickly finds that for showing a summary or a nested column chart is necessary to break the design with some new classes which emerge as Frankenstein objects compared with the existing harmonic set of objects. When I say Frankenstein I want to describe a class which is loosely cohesive and highly coupled to the consumer.

These new objects should not be Frankenstein, they should be well designed and modelled since the beginning but under a different paradigm because although chart series and reports can be adjusted into the OOP paradigm, you will quickly be a victim of the Object-relational impedance mismatch, and thus a Frankenstein objects maker.

Designing a UI-Entity

Imagine you have an application for a movie store. Anywhere in the source code there is a Movie class with attributes like Title or Director. But imagine you need you show a nested column chart with the sum of prices and discounts of each movie sold in the last month. The solution is not breaking your design abstraction with new attributes and new data base related methods to load the information.

A better solution can be bearing in mind the required format during modelling to make your objects easily consumed by the UI-controls and easy to load by the data access layer. In the previous sample the data will be returned by your data base cursor as a sequential collection of rows representing each day in the last month and the respective sums, so you need a new UI-entity to store 3 dynamic data sets, something like:

    public class MovieSerie
    {
        private List<double> discounts = null;
        private List<double> prices = null;
        private List<DateTime> dates = null;
    }

During the years I have reviewed code with alternate solutions which make weird composite objects trying to reuse the Movie class or going wild with jagged arrays (and wild indexes). Make your entities friendly with your object oriented mind and with your layers/controls.

Using the UI-Entity

As you might noted, the MovieSerie attributes are private, resist the temptation to make them public!, it may seem a good idea at first but you will end up filling it as follows:

                dr = db.ExecuteReader(command);
                while (dr.Read())
                {
                    movieSerie.discounts.Add(Convert.ToDouble(dr["DISCOUNT"]));
                    movieSerie.prices.Add(Convert.ToDouble(dr["PRICE"]));
                    movieSerie.dates.Add(Convert.ToDateTime(dr["DATE"]));
                }

That’s terrible! Remember you design to make your life easier and not vice-versa. Consumer classes must not have idea about the internal working of your class, so they don’t care if you have a List or another structure. Encapsulate and you may get something like:

                dr = db.ExecuteReader(command);
                while (dr.Read())
                {
                    movieSerie.AddRow(dr["DISCOUNT"],dr["PRICE"],dr["DATE"]);
                }

This UI Entity should be placed in the layer where it makes more sense (usually the fron-end layer or in any cross-cutting layers).

Cheers,

Javier Andrés Cáceres Alvis

Microsoft Most Valuable Professional – MVP
Intel Black Belt Software Developer