Simple Code Makes Good Software

A typical Windows Forms application might have several forms open at one time. Often these forms share an entity, e.g. they might all be documents related to one customer. Attaching the forms to a customer at creation time is trivial, but making all the forms reflect changes in customer state in real time isn’t. In this example I’ll show a simple mechanism how to bind any number of forms to a set of shared live data.

The Scenario

Let’s assume we have an application where we first select a customer an then create or open any number of invoices (or other documents) related to this customer. A dedicated customer form is used for updating customer details, but in addition to that, any document form might also be used to keep customer data (e.g. the mailing address) up to date. Once a form updates the customer details, all the other forms should reflect the change immediately. The customer might also have calculated characteristics that are not saved as customer data but calculated from documents.

To accomplish this task, we would typically create a network of methods, delegates and events that spreads the signal of data changes between forms. Luckily we don’t have to do that because we already have a mechanism that is easy to use and encapsulates all the methods, delegates and events needed for signaling data changes, namely data binding

The Solution

We create a component class named CustomerSource that inherits from BindingSource. Thanks to its parent class, this component can be dropped on a form, and data controls can be bound to it visually. CustomerSource is internally bound to a typed DataSet, or, to be exact, to a DataTable within that DataSet.

What makes this BindingSource special is that the DataSet is contained in a static member:

private static CustomerDataSet DS = new CustomerDataSet();

This means that a single copy of CustomerDataSet is created when the code for CustomerSource is first loaded. The copy is kept in memory as long as the application runs. Because this single copy is shared by all instances of the class, all the forms that contain a CustomerSource have access to this shared data.

CustomerSource has a double role both as a data model and a controller. It has methods for retrieving, saving and refreshing customer data. These methods are documented in source code.

The Sample Code

You can download the Visual Studio 2005 solution at http://www.sysgen.fi/source/interformcomm. For your convenience it is available both as a ZIP archive and as separate files.

The solution is structured as three Visual Studio projects mainly to demonstrate that static data is not bound to one assembly.

Customer data access uses Microsoft’s Northwind sample SQL Server database. Please open CustomerDataAccess.cs and make sure that sqlConnection1.ConnectionString points to your copy of Northwind if you have got one. If you haven’t got SQL Server or this database, you can run the solution by commenting out an in a few lines in CustomerDataAccess.cs – see source code for instructions! The data access implementation is intentionally simplified: you won’t find any data validation or error handling there.

Enjoy!

Back in the 80′s there were a breed of satiric texts titled like Real Programmers Don’t Use Pascal circulating around Usenet and photocopiers (see Wikipedia or do a web search on this title). Since then, things like OOP, CORBA, COM, and AJAX have been among the major issues that Real Programmers do or don’t use. What remains, however, is that programmers are supposed to write code – right?

So if you are a programmer, you should write as much code as you can because that’s what you are paid for. The more code you write, the better a programmer you will be. The plenitude of your code lines ensures your place in the Programmers’ Hall of Fame!

Not quite so, or, rather, not at all so! In fact, what you are paid for is implementing functionality, not writing code, which is just the necessary evil to accomplish your primary mission. Believe me, even you could write bugs sometimes, and the more code there is, the more bugs there will be. And because nothing is invariable in this world, somebody has to maintain your code after you have finished with it. Whether it is yourself or somebody else, maintaining 10,000 lines of code cannot be easier than maintaining 1,000 lines of code however beautiful those 10,000 lines might ever be.

So how to become a better programmer and write less code? That’s what this blog is trying to figure out. In forthcoming posts I will share my recipes how to utilize the .NET Framework to implement more functionality with less code. And even if you are not a .NET programmer, you might find some posts in this A Craft and an Art category at least intriguing if not downright interesting.

Be my guest!