Lesson 55 - First Pass at the Separation of Concerns Principle

Tutorial Series: Free C# Fundamentals via ASP.NET Web Apps

Previous Article  |  Next Article


Get GitHub Code

There are a variety of principles that you will come across in software development. These principles are meant to apply regardless of the programming language, or the platform, that you're working on. Many of these principles have been cultivated amongst software developers for decades, having become proven guidelines for sound software development. We already saw a few principles and rules of thumb being discussed in previous lessons. We came to understand the “Principle of Single Responsibility,” which states that any given method should do one task and one task only.

Tip:

A general indicator for determining whether or not a method you’re writing violates the Single Responsibility Principle (SRP) is if you need to use the word “and” when verbally describing it. Consider this when saying out loud “this method determines the result (of some process) and formats text for displaying onto the screen.” This could be a clue that this method is doing too much and that these two very different tasks should be housed within their own methods.

Step 1: Understanding SoC via Code Layers

We also understood the rule of thumb of keeping classes as lean and specific as possible – some developers even going so far as to say your class shouldn’t extend past the vertical height of your screen. Continuing on, in this spirit of software design principles, is another principle called the “Separation of Concerns” principle, or “SoC.” This principle describes the steps you take to keep your codebase as loosely coupled as possible, in effort to make it more resilient to change. Change is the sworn enemy of software developers and yet developers face change every single day, such as, changing business requirements, changing code to address fixes, changing API’s, and even changing entire platform dependencies. Change is inevitable, but we can mitigate the impact of change by separating the concerns of an application. There are, typically, three major layers of concern within an average application’s design:

  • The Presentation Layer

  • The Domain Layer

  • The Persistence Layer

The Presentation Layer is concerned with display logic, such as receiving data and presenting it to the user. Then there's the Domain Layer, which is concerned with the Domain Logic, referring to the general business/problem domain that the application solves. For instance, if your application’s main domain deals with keeping an inventory of a warehouse, then that domain layer might process classes and objects that keep track of aspects like items and shipment details. Finally, the Persistence Layer is concerned with handling permanent data storage, including its creation, updating, and retrieval. Whatever information is meant to persist, or remain, between the point that you shut down an application and start it back up again would belong in this Persistence Layer within your application.

This might not seem important because up to this point, we haven't really saved any data into a database or dealt with any persistent information. However, we have been writing applications that contain both presentation concerns and domain concerns. The presentation concern, in an ASP.NET Web Form API, are things like the actual ASP.NET syntax, such as the special ASP syntax mixed in with the HTML:


cs-asp-055---first-pass-at-the-separation-of-concerns-principle.003


There are also the ASP.NET Server Controls, which is an API made available to you when you create Web Form applications. There’s also the ASP.NET event model, which we’ve employed through special methods tied into events, such as Page_Load(), _Click(), and so on. All of those presentation concerns are already taken care of via Microsoft’s existing codebase except for some presentation logic that we’ve written for taking in user input and displaying information back to the user.

The Domain Layer, meanwhile, is all of the business logic that we write. This includes calculations and decision statements bound up within classes that will become the foundation for our major "domain" objects. We've created something resembling this with the methods and properties we defined in elements such as the Character, Hero, and Weapon classes.


Tip:

By seeing a business represented through code a software developer will, oftentimes, come to understand how a given business operates more intimately than subject matter experts within the actual day-to-day operations. The reason is that developers have to come to know every possible decision or consideration in order to automate it properly. They force business owners to answer critical questions to deal with every possible business-related contingency, so as to determine how the code responds based on those contingencies.

Layering your application at a higher level – and employing the Separation of Concerns Principle – means that you should be able to completely replace the database (Persistence Layer) technology that you use without upsetting your core business logic (Domain Layer). By the same token, you should be able to remove the user interface (Presentation Layer) and replace it with some other technology, and your Domain Layer should still work.

Step 2: Anticipating Change by Employing SoC

At this point, you may be wondering if you will ever truly need to worry about fundamentally replacing technologies within your application. The rule of thumb here is “never say never.” Decades of software development has repeatedly proven one thing - change is constant. In the last 20 years, there have been at least a dozen different display technologies, probably half a dozen different ways of accessing databases, including entirely new APIs with entirely new syntax and ways of accessing stored information.

However, this isn't really about swapping out entire layers even if that's something that you could do. Code reuse is a major byproduct of following SoC, but it's just that – a byproduct. Whenever you separate your concerns and use that as a guiding principle in everything that you do, it's going to help you organize your code in such a way that it can be grown to a massive codebase and yet still be maintainable. You will have a manageable codebase with a built-in guidance on where new code belongs in your application, because it belongs to specific concerns. When you fail to separate concerns in this manner, over the course of your application's lifetime, it can become highly resistant to change. A symptom of this would result in your application breaking in multiple places because you change the code in one place in order to update it. Sometimes, it becomes so problematic that it’s simply easier to throw it all away and start again, from scratch, wasting time and resources to do so.

Hopefully by now you can see the usefulness of SoC, so let’s see what it looks like in practice. In the next set of lessons, you will confront concepts related to SoC, such as error/exception handling and variable data storage systems (swapping out one data storage solution with another). Ideally, you would package your concerns separately, into different .NET assemblies that your code is compiled into. In the case of an ASP.NET Presentation Layer, perhaps there are many .aspx pages along with one or more .NET Assemblies/DLL’s. Or perhaps, in the context of having a project within a solution, separating your layers out into separate Visual Studio projects will help your reinforce, and remind you of, the SoC you are trying to follow. From this point on, we're going to be illustrating this idea by being mindful of the given concern of the application and putting each given concern into its own project.

Step 3: Create a Blank Solution to Demonstrate SoC

Here’s the basic shape our employment of SoC will take. Starting with a blank solution, open a new project in Visual Studio, calling it “SomeApp”. Start by selecting:

Templates > Visual C# > Other Project Types > Visual Studio Solutions


cs-asp-055---first-pass-at-the-separation-of-concerns-principle.005


Once opened, right-click on the Solution Explorer and select from the menu:

Add > New Project

From here, create a new ASP.NET Web Application calling it SomeApp.Web:


cs-asp-055---first-pass-at-the-separation-of-concerns-principle.006


Make the project from an Empty template, and include Web Forms:


cs-asp-055---first-pass-at-the-separation-of-concerns-principle.007


Now using those steps, add two more projects to the Solution, each being a Class Library and named “SomeApp.Domain” and “SomeApp.Persistence” respectively:


cs-asp-055---first-pass-at-the-separation-of-concerns-principle.008


When you are done, you should have these three projects in your Solution Explorer:


cs-asp-055---first-pass-at-the-separation-of-concerns-principle.009


This demonstrates basic SoC project structuring within your code into separate layers. You may add, at some point later, other layers relevant to your particular application architecture. For example there might be a Web Services Layer, a custom wrapper around some external API and so on.


Tip:

An API wrapper would let you create a bridge between the code in your application that references an external API and the external API itself. Again, this would be to keep your codebase maintainable – wherever the wrapper is referenced throughout your code – even if the external API changes. For instance, if you were to integrate your app with a payment system, like PayPal or Stripe, you might create.


Related Articles in this Tutorial:

Lesson 1 - Series Introduction

Lesson 2 - Installing Visual Studio 2015

Lesson 3 - Building Your First Web App

Lesson 4 - Understanding What You Just Did

Lesson 5 - Working with Projects in Visual Studio

Lesson 6 - Simple Web Page Formatting in Visual Studio

Challenge 1

Solution 1

Lesson 7 - Variables and Data Types

Lesson 8 - Data Type Conversion

Lesson 9 - Arithmetic Operators

Lesson 10 - C# Syntax Basics

Challenge 2 - ChallengeSimpleCalculator

Solution - ChallengeSimpleCalculator

Lesson 11 - Conditional If Statements

Lesson 12 - The Conditional Ternary Operator

Challenge 3 - ChallengeConditionalRadioButton

Solution - Challenge Conditional RadioButton

Lesson 13 - Comparison and Logical Operators

Lesson 13 Challenge - First Papa Bob's Website

Solution - Challenge First Papa Bob's Website

Lesson 14 - Working with Dates and Times

Lesson 15 - Working With Spans of Time

Lesson 16 - Working with the Calendar Server Control

Challenge 4 - Challenge Days Between Dates

Solution - Challenge Days Between Dates

Lesson 17 - Page_Load and Page.IsPostBack

Lesson 18 - Setting a Break Point and Debugging

Lesson 19 - Formatting Strings

Challenge 5 - Challenge Epic Spies Assignment

Solution - Challenge Epic Spies Assignment

Lesson 20 - Maintaining State with ViewState

Lesson 21 - Storing Values in Arrays

Lesson 22 - Understanding Multidimensional Arrays

Lesson 23 - Changing the Length of an Array

Challenge 6 - Challenge Epic Spies Asset Tracker

Solution - Challenge Epic Spies Asset Tracker

Lesson 24 - Understanding Variable Scope

Lesson 25 - Code Blocks and Nested If Statements

Lesson 26 - Looping with the For Iteration Statement

Challenge 7 - Challenge For Xmen Battle Count

Solution - Challenge For Xmen Battle Count

Lesson 27 - Looping with the while() & do...while() Iteration Statements

Lesson 28 - Creating and Calling Simple Helper Methods

Lesson 29 - Creating Methods with Input Parameters

Lesson 30 - Returning Values from Methods

Lesson 31 - Creating Overloaded Methods

Lesson 32 - Creating Optional Parameters

Lesson 33 - Creating Names Parameters

Lesson 34 - Creating Methods with Output Parameters

Challenge 8 - Challenge Postal Calculator Helper Methods

Solution - Challenge Postal Calculator Helper Methods

Mega Challenge Casino

Solution - Mega Challenge Casino

Lesson 35 - Manipulating Strings

Challenge 9 - Phun With Strings

Solution - Challenge Phun With Strings

Lesson 36 - Introduction to Classes and Objects

Challenge - Hero Monster Classes Part 1

Solution - Hero Monster Classes Part 1

Challenge - Hero Monster Classes Part 2

Solution - Challenge Hero Monster Classes Part 2

Lesson 37 - Creating Class Files Creating Cohesive Classes and Code Navigation

Lesson 38 - Understanding Object References and Object Lifetime

Lesson 39 - Understanding the .NET Framework and Compilation

Lesson 40 - Namespaces and Using Directives

Lesson 41 - Creating Class Libraries and Adding References to Assemblies

Lesson 42 - Accessibility Modifiers, Fields and Properties

Lesson 43 - Creating Constructor Methods

Lesson 44 - Naming Conventions for Identifiers

Lesson 45 - Static vs Instance Members

Challenge 10 - Challenge Simple Darts

Solution - Challenge Simple Darts

Lesson 46 - Working with the List Collection

Lesson 47 - Object Initializers

Lesson 48 - Collection Initializers

Lesson 49 - Working with the Dictionary Collection

Lesson 50 - Looping with the foreach Iteration Statement

Lesson 51 - Implicitly-Typed Variables with the var Keyword

Challenge 11 - Challenge Student Courses

Solution - Challenge Student Courses

Mega Challenge War

Solution - Mega Challenge War

Lesson 52 - Creating GUIDs

Lesson 53 - Working with Enumerations

Lesson 54 - Understanding the switch() Statement

Lesson 55 - First Pass at the Separation of Concerns Principle

Lesson 56 - Understanding Exception Handling

Lesson 57 - Understanding Global Exception Handling

Lesson 58 - Understanding Custom Exceptions

Lesson 59 - Creating a Database in Visual Studio

Lesson 60 - Creating an Entity Data Model

Lesson 61 - Displaying the DbSet Result in an ASP.NET GridView

Lesson 62 - Implementing a Button Command in a GridView

Lesson 63 - Using a Tools-Centric Approach to Building a Database Application

Lesson 64 - Using a Maintenance-Driven Approach to Building a Database Application

Lesson 65 - Creating a New Instance of an Entity and Persisting it to the Database

Lesson 66 - Package Management with NuGet

Lesson 67 - NuGet No-Commit Workflow

Lesson 68 - Introduction the Twitter Bootstrap CSS Framework

Lesson 69 - Mapping Enum Types to Entity Properties in the Framework Designer

Lesson 70 - Deploying the App to Microsoft Azure Web Services Web Apps

Papa Bob's Mega Challenge

Papa Bob's Mega Solution Part 1 - Setting up the Solution

Papa Bob's Mega Solution Part 2 - Adding an Order to the Database

Papa Bob's Mega Solution Part 3 - Passing an Order from the Presentation Layer

Papa Bob's Mega Solution Part 4 - Creating the Order Form

Papa Bob's Mega Solution Part 5 - Adding Enums

Papa Bob's Mega Solution Part 6 - Creating an Order with Validation

Papa Bob's Mega Solution Part 7 - Calculating the Order Price

Papa Bob's Mega Solution Part 8 - Displaying the Price to the User

Papa Bob's Mega Solution Part 9 - Creating the Order Management Page


Comments

Please login or register to add a comment