Practical .NET

Architecting Code in the Presentation Layer

Building your applications so that each part does just one job well makes everything easier. Peter Vogel applies that approach to a Windows Forms app and, in addition to getting it to work, creates a more responsive application.

• By Peter Vogel
• 07/27/2013

The term "architecture" is a metaphor that ties "software design" to "bricks-and-mortar design." If you think of architecture as "the design of rooms and their relationship to each other," the metaphor works well in an object-oriented world: you design objects and establish how they work together. In other ways, though, architecture isn't a great metaphor.

In bricks-and-mortar architecture, each room is designed with a purpose in mind. However, it's a poor bricks-and-mortar design that only allows a room to be used for one thing. Christopher Alexander's "A Pattern Language: Towns, Buildings, Construction" (Oxford University Press, 1977) -- the architecture book that inspired the Gang of Four's "Design Patterns: Elements of Reusable Object-Oriented Software" (Addison-Wesley Professional, 1994) book -- emphasizes how important it is to layer architectural patterns on top of each other to create a rich design. However, in software architecture, the more you layer onto any particular software construct, the harder it will be to get that particular piece of code to work. In software architecture, focus is valued over richness.

As an example, a client gave me a Windows Forms application to complete. The first form I worked on allows users to filter a set of SalesTransaction objects, displayed in a grid. As the user sets filter criteria, the form's code hides and displays rows in the grid. This means the grid is doing two jobs: it's the data store for all the retrieved data, and also the tool for displaying the data. In software architecture, having one component do two things is almost always a bad idea -- as is the case here. You can tell you have problems, for instance, when the standard .NET components won't work.

Refactoring to a Better Design
As soon as I began revising the program, I got an "index out of range" error. The problem turned out to be in a For…Each loop that processes all the rows in the grid. The loop runs just after the rows have been filtered and before the form is redisplayed. This is more than the grid's tiny little brain can handle, and the loop blows up trying to process rows that are no longer in the grid. The grid, for example, might start off displaying 10 rows but, after the user applies a filter, the grid has only seven rows. The For…Each loop, however, stills tries to access row eight … and blows up. Presumably, if the grid had a chance to redisplay, the loop would work correctly.

There's a better architecture for this application that involves separating the data store from the display. In fact, I set up two data stores, both of them Lists. The first List (called AllTransactions) is created as part of the ADO.NET code that retrieves the data:

Private AllTransactions As List(Of SalesTransactions)

dr = cmdSelect.ExecuteReader()
While (dr.Read())
  AllTransactions.Add(New New SalesTransactions(dr(0), ...)
End While

The second collection (called FilteredTransactions) holds the Transactions after the filters are applied. To create that collection, I move AllTransactions into FilteredTransactions and apply a series of LINQ Where methods to reduce the objects in FilteredTransactions. This code, for instance, uses one value from a ComboBox and one from a TextBox to successively filter the SalesTransactions:

Private FilteredTransactions = New List(Of SalesTransactions)

FilteredTransactions = AllTransactions
If (cmbNotificationTypes.SelectedIndex <> 0) Then
  notification = cmbNotificationTypes.SelectedValue
  FilteredTransactions = FilteredTransactions.Where(
    Function(fst) (fst.NotifyType = notification)).ToList()
End If
If txtInsuredName.Text > String.Empty Then
  FilteredTransactions = filteredTransaction.Where(
    Function(fst) (fi.PrimaryName = txtPrimaryName.Text)).ToList()
End If

When I finish filtering, I just set the DataGridView DataSource property to the FilteredTransactions List:

Me.gvTransactions.DataSource = FilteredTransactions

With this new design, the grid is only responsible for displaying the data; the FilteredTransaction List is only responsible for holding the filtered transactions; and the AllTransactions List is only responsible for the original data. More important, each component has a job it can do and the program doesn't blow up. As a benefit, the LINQ code that's filtering the transactions is so fast that I eliminated a button from the form. Instead of forcing the user to click a Search button after changing any criteria, I just redisplay the grid every time the user changes any of the filtering criteria.

Architecture: It's a wonderful thing.