Tutorial Series: Free C# Fundamentals via ASP.NET Web Apps
Previous Article | Next Article
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.
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.
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.
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.
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
Lesson 7 - Variables and Data Types
Lesson 8 - Data Type Conversion
Lesson 9 - Arithmetic Operators
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
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
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 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