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:
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
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:
Make the project from an Empty template, and include Web Forms:
Now using those steps, add two more projects to the Solution, each being a Class Library and named “SomeApp.Domain” and “SomeApp.Persistence” respectively:
When you are done, you should have these three projects in your Solution Explorer:
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.