I know this has been beaten to death in some circles (521,000 results in Google, 2,551 results in Google’s blog search), but it bears repeating until people start paying it some attention. Separation of Concerns is the concept that software areas exist with as little overlap as possible. The existence of distinct logical layers within your code is an example of the start of creating good separation of concerns. A layer exist for the UI, another layer exists for Data Access, and on and on. Each layer is concerned with one aspect of the application.

Today I saw the complete lack of separation of concerns on my project. Note that this project has no concept of a dynamically generate user interface. A stored procedure was presented that had intimate knowledge about the controls that were to be displayed in the user interface. The stored procedure’s output provided both data and the control type that said data should be displayed in. So a return result might have looked something like this:

The blurring of concerns here, isn’t so much a blurring as it’s a complete erasing of it. To change the physical display of data on the screen, a stored procedure (data access component) must be changed. Because there’s a significant group of people in the industry that don’t seem to be catching on to why this is a problem, let’s look at it in a bit more detail.

In this situation there are two distinct concerns in the life of the application; Displaying data (UI) and retrieving data (data access). Both have distinctly different requirement. When displaying data the application is dealing with screen colour, font information, control location, interaction points, etc. All of these things relate to the experience of the user. The standard user’s primary concern doesn’t include what table in the database the information comes from, if/how logging is occurring, ORM vs Stored Proc, etc.

The second concern that is identifiable in this scenario is data access. DALs are quite well known in the industry. All a DAL is is a logical layer within your application. Simply having a DAL is a decent first step to separating out the concerns surrounding your data access methods, techniques and nuances. It is just a start though. A data access layer will be concerned, in some way that is tied to the technology that you’re using, with things like creating connections, queries and transactioning. All of those things, plus some others, have to do with the physical interaction between your code and the data storage repository. That physical interaction includes anything that lays between table, column, row and your application. It might be that the interaction uses inline parameterized queries or it could be using stored procedures. Both of those are part of your DAL along with the C#, VB, Java, whatever code that is managing the connections, transactioning, ect.

So what is the problem with what I saw at work today? If the user interface is concerned with the formatting, layout, and control rendering of the screen, why does the stored procedure need to know about it? By putting the control type decision into the stored procedure we’ve made every layer between the UI and the DAL (and there should be a few different logical layers in there) aware of the UI implementation. Yes, not all, or even any, of those logical layers will actively interact with the control type information, but it is there which means each layer is aware of it. The bigger issue is that we’ve now tightly coupled our UI and stored proc. The UI is dependent on the stored proc for it to render correctly. If the stored proc changes, the UI will render differently (outside of the data displayed within the layout/structure of the UI). The coupling is also reversed. The stored procedure is now has to be intimately knowledgeable about the capabilities of the UI that is being implemented. If we moved from a webform to winform implementation there is a very high probability that the stored procedure would need changes to allow it to continue to work.

The capability of one logical layer or concern in the application is directly tied to the implementation in another. Separating each concern will allow you to work in a section of the application with less worry about the implications in another layer or concern.

None of this is an exact and quantifiable science, but every developer in the industry should be able to notice where concerns are being blurred or mixed. If you can’t notice this, I’d strongly suggest that you need to look at changing your career to something that involves less abstraction. Yes, I said it. If you can’t conceive of software at this level of abstract get a different job. You’re not cut out to qualify as a software developer. All you are is a hobbyist that is getting paid. Separation of Concerns is a fundamental practice that all developers need to understand. The size of your application is irrelevant. The expected life of your application is usually irrelevant. The technology that you use is irrelevant. Maintainability, changeability and reverseability are relevant though. Those are some of the things that make applications that sustain the trials of time and business changes.

[Note] Jimmy Bogard has started a series on separation of concerns. It’s a little more hands on than this rant. How not to do it and Part 1