Separation of Concerns Pattern in Custom Software Development

When it comes to custom software development, tools and technologies seem to encounter a paradigm shift at a dizzying pace.

The developer is faced with the unintended problem of too many choices and ways of doing things.

This can lead to choices that jeopardize the success of a project. For example, choosing to implement an application using web technology when a simpler Win form approach would accomplish the same thing is a common mistake. There seems to be a herd mentality or affinity to a technology when it comes to these fundamental decisions.

Sometimes the “cool” factor influences the decision-making process by a desire to be “cutting edge,”, or a one size fits all mentality in a desire to make software development more repeatable and seemingly more efficient. Often fear of the unknown drives the decision, whereby the developers slated for the project have never used a certain technology, therefore never consider alternatives to anything other than what they are already familiar with. They “run home to mamma,”, so to speak.

So how do we navigate this persistent conundrum when making sound architectural decisions? The answer is in a word, patterns.

Patterns
Patterns do not know what year they are living in. They are technology agnostic for the most part. Almost every problem a software developer will face or has ever faced has been solved or mitigated by a pattern. There are low level code patterns and high level topology patterns and everything in between that should be considered when solving a problem with software.

Patterns can get you into trouble if you are not careful. You can find yourself in the situation of a pattern in search of a problem. Using a pattern that is not suited for a particular problem can over-complicate the code and make the application brittle and hard to maintain. Use patterns with caution. Make sure you understand the problem fully before you consider a pattern for the solution.

There are a many books and articles that explain and demonstrate patterns, most famously the Gang of Four’s book that codified low level software patterns thirty years ago still in use today. One pattern that is almost universal to a successful application is called separation of concerns.

4 Layers Needed in a Separation of Concerns Pattern
Separation of concerns simply means organizing the code in a way that focuses its purpose. User Interface code should not contain any business logic. The business layer should not contain any data access code. The stored procedures should not contain any business logic. This pattern that will almost guarantee a decent outcome involves separating the code into four distinct layers: Database, Data Access, Business and User Interface.

Database Layer
The database layer is simply a collection of stored procedure that serves up or persists data for the application. They should consist almost entirely of what are called CRUD procs. Create, Read, Update, and Delete. If your stored procedure does any more than this you might on the wrong path. Obviously there are no absolutes but you should consider making these code elements focused on a singular task making them more reusable and easier to maintain.

Data Access Layer
The Data Access layer is a simple layer that is utilitarian in nature. It sole purpose is to connect to the database and execute stored procedures or build business objects to send back to the business layer. There should no business logic at all in this layer.

Business Layer
The next layer up the food chain is the business layer. This contains definitions of business objects that the data layer populates and classes that contain business logic. The business layer is where all of the business logic should be contained and what the User Interface uses to populate its controls. The business layer should not care about what type of UI is being used be it Web, Win or Mobile device, for example.

User Interface
Finally, there is the User Interface or UI as it were. This layer consumes the business layer and has no knowledge of how the data is fetched or persisted. It simply calls methods in the business layer to fulfill its mission.

So what does this approach buy a software development project?
First, it does not matter what technology is being used. Whether it’s java or .NET, SQL or Oracle it does not matter. This allows the appropriate choices for each layer to be considered independently. It also allows for greater testability including automated testing improving code quality. Perhaps its greatest advantage is flexibility and maintainability.

Decoupling the layers in this fashion allows the code to shift when needed and not affect the adjacent layers for the most part. A stored procedure can change and not necessarily affect the data layer. Or if the data layer needs to change, as long as its interface is unaffected the business layer and UI have no worries. Finally separating these concerns logically also allows you to separate these concerns physically. This in turn allows each layer to be scaled out to multiple machines or independently tuned if necessary.

Separating concerns is almost a universal hallmark of a quality application. It seems so simple on its surface yet too many times application code gets gnarled up by mixing business logic across logical boundaries. This makes the application hard to maintain and debug therefore reducing ROI. The moral of story is; Use patterns diligently, separate your concerns, avoid a one size fits all mentality and consider alternative technologies when architecting a solution.

Acquiring the wisdom to identify when a pattern could be useful, and consistently implementing sound software development methodologies takes time. Understanding the “how” is relatively easy. Understanding the “why” can take years to sink in.

About the Author
Lee Bryant is a Technical Manager at Tribridge. He has over 11 years of software development experience in design, development, testing, implementation, integration, and production support.