Design and Architecture of the .NET Application

Introduction

 

In my previous article, I talked about building a sample application that will be built to demonstrate the four most common types of applications. These include a desktop, web, cloud and mobile application. Before we start writing this application in each of these four formats, let's finalize the business solution of the application and the design and architecture of it. We certainly need to know what we are developing and the general layout of any application before we start building it. That is what we are going to see in this article.

 

What does the application do?

 

Before we start building an application, we need to know what an application is going to do. This is to define what the application is going to help the end-user to achieve. Even the best-designed and most complex applications that do not achieve this result are basically of no use to the end-user. Every application must be designed and developed with the end-user in mind. For this series of articles, the focus will not be much on the type of application but rather on the architecture and development process of how to build a basic application for the desktop, web, cloud and mobile user. Hence, the application will be a simple “Employee” records application.

 

The Employees record application

 

In this application, we will simply maintain the records of employees in a company. We will store the employee ID, employee name, age, address, date of joining and date of leaving. The data will be stored in a SQL Server relational database. There will be only one table called “Employee” to keep the application simple.

 

Data field	Description
Employee ID	The unique identifier of the employee
Employee Name	First and Last name of the employee
Age	The age of the employee
Address	The address of the employee
Date of Joining	The joining date of the employee
Date of Leaving	The leaving date of the employee

 

The Logical Architecture of the application

 

Although the application architecture may vary depending upon the type of application we built, I strongly believe that a basic logical architecture must always be put into place even before we start to think in technical terms. This is important to ensure the application meets the basic benchmarks of scalability, maintainability, performance, extensibility, and application of security.

 

For this series of articles, I will talk about the most basic layers of application architecture, shown below:

1. The User Interface or Front-end application layer
2. The Business Logic or Middle-tier application layer
3. The Data Access application layer
4. The Data Store

Let's take a brief look at each one of the above:

 

The front-end application layer

This is the layer or part of the application with which the user will directly interact. Hence, it is a very important part of any application. The applications with the best performance benchmarks will be of little use if the end-user cannot easily understand how to work with the application. This layer mostly consists of a set of controls like text boxes to enter data, buttons to click to initiate actions and menus to select a particular action from. The type of application will determine the technology used to create these sets of controls and how they are handled but the basic terminology remains the same. The front end or user interface of any application must be very easy to understand and use for the end-user. We will design and develop the front end for each application as we work through the samples.

 

The middle-tier application layer

This layer holds the core logic of the application. It is in this layer that we write the code which does the calculations, decision making, and all business rules are applied. That is why it is sometimes also called the business logic layer. We will not be writing any complex business rules in this series of articles. However, I will add some simple sample code to illustrate the point of this layer when we get to the sample applications.

 

The data access application layer

This layer is simply to communicate with the underlying data store. The question that might come to mind is why do we need a separate layer just to pass on our data to the data store? Why don’t we just keep this in the business logic layer? The reason for this is that in the future if we decide to move to a new technology to store the data, we would only need to make changes in the data access layer and not have to touch the business logic layer. Therefore, we can say that this layer keeps the business logic layer away from data storage details and allows it to concentrate solely on keeping business logic details.

 

The data store

This is the place where the data we need to persist are kept. It is probably the most important layer of any application. Clearly, no application would be of any use if it did not store data and if that data could not be retrieved for analysis. The type of store we choose again depends upon the type of data we are trying to store. For this series of articles and the applications that we are going to develop, we will be using a relational database. I will discuss it when we look at the first type of application in detail.

 

Summary

 

Before we delve into the technical details of any application and start to put together the application’s technical design and architecture, we first need to understand what the application will do, what type of information will it store and how that information will be presented to the user. We also need to layout the general design and architecture of the application considering requirements for scalability, maintainability, performance, extensibility and the application of security. These items have been covered in this article. Next, we will move into developing the first type of application, i.e. the desktop application.