Recently I was asked by a client to review some in-house applications. The client explained his pain point - “Every time we make a change something else breaks”.

This is a portent for solutions that violate two important principles:  separation of concerns and the single responsibility principle. These solutions have serious drawbacks. Components are tightly coupled – change one and you have to change many others. Identifying and isolating the impact of changes in this type of architecture is difficult even with great documentation. These applications are often developed over time in environment with little knowledge of development methodology. Testing is adhoc and documentation non existent so isolating change is virtually impossible.

What is separation of concerns? Separation of concerns is the process of architecting a solution into distinct logical units that overlap in functionality as little as possible. A concern is synonymous with features or behaviours.

The single responsibility principle states that every object or class has a single responsibility and one, and only one, reason for change.  An object or class should be focused on a single concern.

Let’s look at a simple example. You are asked to write a suite of management reports in SQL Server Reporting Services. The Finance and Marketing departments have specified their respective reports however some of the reports are common to both departments. What is the best strategy to design the reports? There are two possibilities:

  • Create stored procedures for each unique reports
  • Create stored procedures for each unique reports for each department

Marketing requests a change to a common report – which solution requires the least effort to make the change? Which requires the least amount of testing? Which is more maintainable?

Here is another example. The release of Visual Studio 2003 introduced design-time data tools for ADO.NET data access.  This gave rise to "facade-like" design  pattern that used data adapters and strongly typed datasets in monolithic VB.NET applications.  Data adapters are ADO.NET objects that reference SQL commands or stored procedure.  Typed datasets are defined by an XML schema file and a DataSet object.

This "facade-like" pattern is implemented by using a Windows form as a container to host the data connection, data adapters and typed dataset objects. The schema file is created at design-time by the dataset objects.  The result  is several tightly coupled data access objects in your application.

Let us add a new column in an underlying table in the database.  To propagate the schema change, you have to use the design-time tools to update the data adapter, generate a new schema file, test, recompile and release the application.  This is a non-trivial exercise if you have 100 users and you simply added a new column to a table.

In the December 2004 issue of MSDN Magazine, John Papa discussed strongly typed datasets and makes this important point.

Keep in mind that when you use a typed DataSet, if the corresponding schema changes in the underlying database table, you will need to synchronize the schema in the typed DataSet. This is not a big deal because when you use an untyped DataSet you would still likely have to change some client code if the underlying schema changes.

It is true that some schema modifications require change in your code however this is not always the case.  In a loosely coupled application with good separation of concerns, change to client code is the exception rather than the rule.  With tightly coupled data access components, code changes are always necessary when the underlying tables are modified.

The solution architecture of a client application can anticipate change with these simple rules:

  • Avoid monolithic application
  • Use loosely coupled components
  • Refactor database code based on the single responsibility principle
  • Design components with good separation of concerns

Solutions developed with this approach are easier to maintain and embrace rather than resist change.  You turn a pain point into a benefit and you more likely to hear "Every time we make a database change it's transparent to my applications".

TAGS: , , ,