presentation business layer

• Engineering Mathematics
• Discrete Mathematics
• Operating System
• Computer Networks
• Digital Logic and Design
• C Programming
• Data Structures
• Theory of Computation
• Compiler Design
• Computer Org and Architecture

Business-Logic Layer

In this article, we are going to learn about the Business Logic Layer in Database Management systems. The Business Logic Layer also known as BLL act as an intermediate between the Presentation Layer and the Data Access Layer (DAL). This layer handles the business logic, business rules as well as calculations. It tells how the data from the database can be used, what it can perform, and what can not within its application.

The Business-Logic Layer (BLL) is a component of a software architecture that is responsible for implementing the business logic of an application. It sits between the presentation layer (e.g., the user interface) and the data access layer (e.g., the database), and is responsible for processing and manipulating data before it is presented to the user or stored in the database.

The BLL is responsible for performing tasks such as: -Validating input data to ensure that it meets the necessary business rules and constraints. -Performing calculations and transformations on data, as required by the business logic. -Enforcing business rules and policies, such as access control and security. -Communicating with the data access layer to retrieve and store data. -Handling errors and exceptions.

The BLL is designed to be reusable and independent of the user interface and data storage implementation. This allows the application to be easily modified or extended without affecting the underlying business logic.

The BLL is also responsible for managing the workflows and the use cases of the application, by handling the communication between the different layers, and by implementing the rules and constraints of the business.

In summary, The Business-Logic Layer (BLL) is a component of a software architecture that is responsible for implementing the business logic of an application. It sits between the presentation layer and the data access layer, and is responsible for processing and manipulating data before it is presented to the user or stored in the database. It also manages the workflows and the use cases of the application, and it is designed to be reusable and independent of the user interface and data storage implementation.

• Presentation Layer: The layer at which users interact with the application and the final data will be visible to the users at this interface. It acts as an interface between the user and the application.
• Business Logic Layer: It acts as an intermediate between the Presentation and the Data Access Layer.
• Data Access Layer: The layer at which the data is managed.

Business Logic Layer

• All the three layers above play an important role in building an application
• The business logic layer manages the communication between the database and the presentation layer.

Example: In an application, when the user access it or write queries in it with the help of a presentation or user interface layer the business logic layer helps the user to get a response to the asked queries by transferring it to the Data Access layer which further processes the query and give the suitable result to a business logic layer which is further transferred to the presentation layer which makes it visible to the user.

Due to the less clarity in defining the Business logic layer, some business domains like Microsoft and Apple excluded the BLL from their applications which leads to difficulty in code maintenance. A better approach is to build an application that supports multiple different user Interfaces.

Advantages of Business Logic Layer:

• Code Maintenance is easy: Maintaining the code will be easy when we are using the Business Logical Layer as it supports multitier architecture. By using this we can easily determine any kind of change in the code.
• Security: This architecture provides us the security as we can see that the Presentation layer doesn’t directly interact with the Data Access Layer which prevents it from any kind of data loss and ensures that the data is secure at the Data layer.
• Application releases: It makes application release rollout easy. Because the Business Logic Layer is the only one to be updated every time then we do not need other layers of architecture i.e. the Presentation layer and the Data Access Layer.
• Ease of learning: It is easy to learn because the learner has to specialize only in the presentation, data, and business layer to more quickly learn the specific parts of the application. The development time taken by the application will be small as all the layers can work together at the same time.

Disadvantages of Business Logic Layer:

• Expensive: It will be very difficult and expensive to install and maintain this layer in databases.
• Source control is very difficult to perform properly with existing procedures.
• It makes it difficult to use the code, again and again, such that it decreases code reusability .

Applications of Business Logic Layer:

• BLL has a major application in building multi-tier applications.
• It is most commonly used in creating component-based applications.

Similar Reads

• Computer Subject

Please Login to comment...

• How to Underline in Discord
• How to Block Someone on Discord
• How to Report Someone on Discord
• How to add Bots to Discord Servers
• GeeksforGeeks Practice - Leading Online Coding Platform

Improve your Coding Skills with Practice

What kind of Experience do you want to share?

Software Architecture Patterns by

Get full access to Software Architecture Patterns and 60K+ other titles, with a free 10-day trial of O'Reilly.

There are also live events, courses curated by job role, and more.

Chapter 1. Layered Architecture

The most common architecture pattern is the layered architecture pattern, otherwise known as the n-tier architecture pattern. This pattern is the de facto standard for most Java EE applications and therefore is widely known by most architects, designers, and developers. The layered architecture pattern closely matches the traditional IT communication and organizational structures found in most companies, making it a natural choice for most business application development efforts. 

Pattern Description

Components within the layered architecture pattern are organized into horizontal layers, each layer performing a specific role within the application (e.g., presentation logic or business logic). Although the layered architecture pattern does not specify the number and types of layers that must exist in the pattern, most layered architectures consist of four standard layers: presentation, business, persistence, and database ( Figure 1-1 ). In some cases, the business layer and persistence layer are combined into a single business layer, particularly when the persistence logic (e.g., SQL or HSQL) is embedded within the business layer components. Thus, smaller applications may have only three layers, whereas larger and more complex business applications may contain five or more layers. 

Each layer of the layered architecture pattern has a specific role and responsibility within the application. For example, a presentation layer would be responsible for handling all user interface and browser communication logic, whereas a business layer would be responsible for executing specific business rules associated with the request. Each layer in the architecture forms an abstraction around the work that needs to be done to satisfy a particular business request. For example, the presentation layer doesn’t need to know or worry about how to get customer data; it only needs to display that information on a screen in particular format. Similarly, the business layer doesn’t need to be concerned about how to format customer data for display on a screen or even where the customer data is coming from; it only needs to get the data from the persistence layer, perform business logic against the data (e.g., calculate values or aggregate data), and pass that information up to the presentation layer.  

Figure 1-1. Layered architecture pattern

One of the powerful features of the layered architecture pattern is the separation of concerns among components. Components within a specific layer deal only with logic that pertains to that layer. For example, components in the presentation layer deal only with presentation logic, whereas components residing in the business layer deal only with business logic. This type of component classification makes it easy to build effective roles and responsibility models into your architecture, and also makes it easy to develop, test, govern, and maintain applications using this architecture pattern due to well-defined component interfaces and limited component scope.

Key Concepts

Notice in Figure 1-2 that each of the layers in the architecture is marked as being  closed . This is a very important concept in the layered architecture pattern. A closed layer means that as a request moves from layer to layer, it must go through the layer right below it to get to the next layer below that one. For example, a request originating from the presentation layer must first go through the business layer and then to the persistence layer before finally hitting the database layer. 

Figure 1-2. Closed layers and request access

So why not allow the presentation layer direct access to either the persistence layer or database layer? After all, direct database access from the presentation layer is much faster than going through a bunch of unnecessary layers just to retrieve or save database information. The answer to this question lies in a key concept known as  layers of isolation . 

The layers of isolation concept means that changes made in one layer of the architecture generally don’t impact or affect components in other layers: the change is isolated to the components within that layer, and possibly another associated layer (such as a persistence layer containing SQL). If you allow the presentation layer direct access to the persistence layer, then changes made to SQL within the persistence layer would impact both the business layer and the presentation layer, thereby producing a very tightly coupled application with lots of interdependencies between components. This type of architecture then becomes very hard and expensive to change.  

The layers of isolation concept also means that each layer is independent of the other layers, thereby having little or no knowledge of the inner workings of other layers in the architecture. To understand the power and importance of this concept, consider a large refactoring effort to convert the presentation framework from JSP (Java Server Pages) to JSF (Java Server Faces). Assuming that the contracts (e.g., model) used between the presentation layer and the business layer remain the same, the business layer is not affected by the refactoring and remains completely independent of the type of user-interface framework used by the presentation layer.  

While closed layers facilitate layers of isolation and therefore help isolate change within the architecture, there are times when it makes sense for certain layers to be open. For example, suppose you want to add a shared-services layer to an architecture containing common service components accessed by components within the business layer (e.g., data and string utility classes or auditing and logging classes). Creating a services layer is usually a good idea in this case because architecturally it restricts access to the shared services to the business layer (and not the presentation layer). Without a separate layer, there is nothing architecturally that restricts the presentation layer from accessing these common services, making it difficult to govern this access restriction.  

In this example, the new services layer would likely reside  below  the business layer to indicate that components in this services layer are not accessible from the presentation layer. However, this presents a problem in that the business layer is now required to go through the services layer to get to the persistence layer, which makes no sense at all. This is an age-old problem with the layered architecture, and is solved by creating open layers within the architecture.  

As illustrated in Figure 1-3 , the services layer in this case is marked as open,  meaning requests are allowed to bypass this open layer and go directly to the layer below it. In the following example, since the services layer is open, the business layer is now allowed to bypass it and go directly to the persistence layer, which makes perfect sense.  

Figure 1-3. Open layers and request flow

Leveraging the concept of open and closed layers helps define the relationship between architecture layers and request flows and also provides designers and developers with the necessary information to understand the various layer access restrictions within the architecture. Failure to document or properly communicate which layers in the architecture are open and closed (and why) usually results in tightly coupled and brittle architectures that are very difficult to test, maintain, and deploy.

Pattern Example

To illustrate how the layered architecture works, consider a request from a business user to retrieve customer information for a particular individual as illustrated in Figure 1-4 . The black arrows show the request flowing down to the database to retrieve the customer data, and the red arrows show the response flowing back up to the screen to display the data. In this example, the customer information consists of both customer data and order data (orders placed by the customer).  

The customer screen is responsible for accepting the request and displaying the customer information. It does not know where the data is, how it is retrieved, or how many database tables must be queries to get the data. Once the customer screen receives a request to get customer information for a particular individual, it then forwards that request onto the customer delegate module. This module is responsible for knowing which modules in the business layer can process that request and also how to get to that module and what data it needs (the contract). The customer object in the business layer is responsible for aggregating all of the information needed by the business request (in this case to get customer information). This module calls out to the  customer dao  (data access object) module in the persistence layer to get customer data, and also the order dao module to get order information. These modules in turn execute SQL statements to retrieve the corresponding data and pass it back up to the customer object in the business layer. Once the customer object receives the data, it aggregates the data and passes that information back up to the customer delegate, which then passes that data to the customer screen to be presented to the user.      

Figure 1-4. Layered architecture example

From a technology perspective, there are literally dozens of ways these modules can be implemented. For example, in the Java platform, the customer screen can be a (JSF) Java Server Faces screen coupled with the customer delegate as the managed bean component. The customer object in the business layer can be a local Spring bean or a remote EJB3 bean. The data access objects illustrated in the previous example can be implemented as simple POJO’s (Plain Old Java Objects), MyBatis XML Mapper files, or even objects encapsulating raw JDBC calls or Hibernate queries. From a Microsoft platform perspective, the customer screen can be an ASP (active server pages) module using the .NET framework to access C# modules in the business layer, with the customer and order data access modules implemented as ADO (ActiveX Data Objects). 

Considerations

The layered architecture pattern is a solid general-purpose pattern, making it a good starting point for most applications, particularly when you are not sure what architecture pattern is best suited for your application. However, there are a couple of things to consider from an architecture standpoint when choosing this pattern.

The first thing to watch out for is what is known as the architecture sinkhole anti-pattern . This anti-pattern describes the situation where requests flow through multiple layers of the architecture as simple pass-through processing with little or no logic performed within each layer. For example, assume the presentation layer responds to a request from the user to retrieve customer data. The presentation layer passes the request to the business layer, which simply passes the request to the persistence layer, which then makes a simple SQL call to the database layer to retrieve the customer data. The data is then passed all the way back up the stack with no additional processing or logic to aggregate, calculate, or transform the data. 

Every layered architecture will have at least some scenarios that fall into the architecture sinkhole anti-pattern. The key, however, is to analyze the percentage of requests that fall into this category. The 80-20 rule is usually a good practice to follow to determine whether or not you are experiencing the architecture sinkhole anti-pattern. It is typical to have around 20 percent of the requests as simple pass-through processing and 80 percent of the requests having some business logic associated with the request. However, if you find that this ratio is reversed and a majority of your requests are simple pass-through processing, you might want to consider making some of the architecture layers open, keeping in mind that it will be more difficult to control change due to the lack of layer isolation. 

Another consideration with the layered architecture pattern is that it tends to lend itself toward monolithic applications, even if you split the presentation layer and business layers into separate deployable units. While this may not be a concern for some applications, it does pose some potential issues in terms of deployment, general robustness and reliability, performance, and scalability.   

Pattern Analysis

The following table contains a rating and analysis of the common architecture characteristics for the layered architecture pattern. The rating for each characteristic is based on the natural tendency for that characteristic as a capability based on a typical implementation of the pattern, as well as what the pattern is generally known for. For a side-by-side comparison of how this pattern relates to other patterns in this report, please refer to  Appendix A  at the end of this report.

Get Software Architecture Patterns now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Don’t leave empty-handed

Get Mark Richards’s Software Architecture Patterns ebook to better understand how to design components—and how they should interact.

It’s yours, free.

Check it out now on O’Reilly

Dive in for free with a 10-day trial of the O’Reilly learning platform—then explore all the other resources our members count on to build skills and solve problems every day.

Exploring the 3 layers of software interactions (APIs)

Application Programming Interfaces, commonly known as APIs, are a set of protocols, routines, and tools that enable software applications to interact with each other. They allow different software applications to exchange information seamlessly and efficiently.

APIs have become increasingly important in today's digital world, as they enable developers to build powerful applications that can connect with other services and platforms. APIs can be broken down into three different layers, each of which serves a different purpose.

In this blog post, we will explore the three layers of APIs and what they do.

1. Presentation Layer

The presentation layer, also known as the "API endpoint," is the layer that developers interact with most frequently. This layer provides a user-friendly interface for developers to access the functionality and data of the underlying service. It is responsible for processing incoming requests and returning responses in a format that developers can easily understand.

The presentation layer can take many different forms, depending on the requirements of the API. It could be a REST API that uses HTTP requests to exchange data or a SOAP API that uses XML messages to communicate. Regardless of the specific implementation, the presentation layer is the public-facing aspect of the API and is the first point of contact for developers.

2. Business Logic Layer

The business logic layer, also known as the "API middleware," is the layer that contains the core logic of the API. It is responsible for processing the requests received from the presentation layer and generating responses based on the requested actions.

The business logic layer is where the API's core functionality resides. It may perform data validation, authentication and authorization, database queries, or other complex operations. This layer is typically developed by the service provider and is not exposed directly to developers.

3. Data Storage Layer

The data storage layer, also known as the "API database," is the layer where all of the data used by the API is stored. This layer is responsible for managing data storage, retrieval, and modification. It may use a variety of database technologies such as SQL, NoSQL, or object-oriented databases.

The data storage layer is the most critical component of the API since it holds the data that the API relies on. If the data storage layer fails, the entire API may fail. Therefore, it is crucial to ensure that the data storage layer is designed and implemented correctly.

In conclusion, APIs consist of three layers: presentation layer, business logic layer, and data storage layer. Each layer plays a crucial role in the API's functionality and performance. Understanding the three layers of an API is essential for developers looking to build robust, reliable, and scalable APIs.

Related articles

What is Application Programming Interface (API)?

An API is a set of rules and practices that allow two applications to communicate. This means that one can use one application to retrieve data from another application or send data to another application.

Layered Architecture

Last updated: November 11, 2021

• Software Architecture

Baeldung Pro comes with both absolutely No-Ads as well as finally with Dark Mode , for a clean learning experience:

>> Explore a clean Baeldung

Once the early-adopter seats are all used, the price will go up and stay at $33/year.

1. Introduction

In this article, we’re going to look at the layered architecture in software development. We’ll give an overview of what it is, its components, and outline its characteristics. Next, we’ll also describe the benefits and drawbacks, and give examples of situations where they are appropriate for use.

Before we begin, let’s first define software architecture.

2. Definitions

Software architecture refers to the basic structure of any software system and incorporates any aspect that makes a system function and behaves as it should . Although the term architecture usually refers to physical designs, in software systems, it encompasses the design of components, relationships between components, user interactions, as as well as the user’s needs of a system.

There are several different software architectures that exist such as microkernels, microservices , and client-servers just to name a few. Each of these is structured differently and is used in a different context. However, we’ll only look at layered architectures in this article.

3. What Is a Layered Architecture?

Layered architectures are said to be the most common and widely used architectural framework in software development. It is also known as an n-tier architecture and describes an architectural pattern composed of several separate horizontal layers that function together as a single unit of software . A layer is a logical separation of components or code:

In these frameworks, components that are related or that are similar are usually placed on the same layers . However, each layer is different and contributes to a different part of the overall system.

3.1. Characteristics

A major characteristic of this framework is that layers are only connected to the layers directly below them. In the illustration given previously, layer 1 only connects to layer 2, layer 2 connects to layer 3, and layer 1 is connected to layer 3 only through layer 2.

Another characteristic is the concept of layers of isolation . This means that layers can be modified and the change won’t affect other layers . In short, changes are isolated to the specific layer that is altered.

Separation of concerns is another notable feature that speaks to how the modules on a single layer together perform a single function .

4. Components of a Layered Architecture

Now, the number of layers in a layered architecture is not set to a specific number and is usually dependent on the developer or software architect. It is important to note that this framework will usually always have a user interaction layer, a layer for processing, and a layer that deals with data processing. These are described further as:

• Presentation Layer – responsible for user interactions with the software system
• Application/Business Layer – handles aspects related to accomplishing functional requirements
• Domain Layer – responsible for algorithms, and programming components
• Infrastructure/Persistence/Database Layer – responsible for handling data, databases

Additionally, in some applications, some layers are combined. For example, it is common to find the business layer and persistence layer combined into a single layer. This just means that the functions and responsibilities of these two layers have been grouped to occur at a single layer.

5. Advantages and Disadvantages

The following are the benefits and drawbacks that exist with this software pattern:

• The framework is simple and easy to learn and implement.
• There is reduced dependency because the function of each layer is separate from the other layers.
• Testing is easier because of the separated components, each component can be tested individually.
• Cost overheads are fairly low.

Disadvantages

• Scalability is difficult because the structure of the framework does not allow for growth.
• They can be difficult to maintain. A change in a single layer can affect the entire system because it operates as a single unit.
• There is interdependence between layers since a layer depends on the layer above it to receive data.
• Parallel processing is not possible.

6. When to Use Layered Architectures

When developing simple, small applications, it is advisable to implement a layered architecture because it’s the most simple framework. However, some developers are of the opinion that because they can be difficult to maintain, it is better to apply them to larger projects.

In spite of this, the framework can be used for applications that need to be built quickly because it’s easy to learn and implement. It is also good in cases where the developers do not have a lot of knowledge of software architectures or when they are undecided on which one to use.

Some real-life applications of this architecture are in web applications and the OSI model . The J2EE programming model also implements the layered architecture.

7. Conclusions

In this article, we’ve defined layered architectures. We’ve also discussed their characteristics and the basic components that exist. We’ve looked at the benefits and drawbacks and have also detailed scenarios where it is appropriate to use them.

• +1 855.488.5327
• [email protected]
• Mon - Fri: 9:00am - 5:00pm ET

The Phases of the Software Development Life Cycle (SDLC)

Navigating the Future of Work with AI: Embrace Change and Thrive in a Tech-Driven World

How to Create and Implement an SPF Record for Email Security

• Live Webinars
• What Is the Presentation Layer in the OSI Model?

The Presentation Layer is the sixth layer of the OSI (Open Systems Interconnection) model. It plays a crucial role in translating and formatting data between the application layer and the network. Often referred to as the “translator” of the OSI model, the Presentation Layer is responsible for data encoding, encryption, compression, and formatting. This layer ensures that data sent from one device is in a format that the receiving device’s application can interpret and use, even if the two systems use different data formats.

Definition: Presentation Layer

The Presentation Layer in the OSI model is responsible for translating data between the application and network layers, ensuring compatibility between different systems. It handles tasks such as data encryption, compression, encoding, and conversion to ensure that the data is in the correct format and can be understood by both the sender and the receiver.

Key Functions of the Presentation Layer

The Presentation Layer provides several key services that ensure data is presented in a way that can be understood by the receiving application:

• Data Translation: The Presentation Layer translates data between the formats used by the application layer and the underlying network layer. This ensures that data from different platforms can be exchanged and understood.
• Data Encryption and Decryption: For secure communication, the Presentation Layer encrypts data before it is transmitted across the network and decrypts it upon arrival, ensuring privacy and confidentiality.
• Data Compression and Decompression: To optimize bandwidth usage, the Presentation Layer compresses data before sending it over the network and decompresses it when it is received.
• Character Encoding: It converts data from one character encoding set to another, for example, ASCII to EBCDIC or Unicode, to ensure that both systems can correctly interpret text data.
• Syntax Handling: The Presentation Layer handles syntax conversion, ensuring that different systems using varying data structures can successfully communicate.

Data Translation in the Presentation Layer

One of the fundamental roles of the Presentation Layer is data translation . Since applications may use different data formats (such as numbers, characters, or file formats), the Presentation Layer translates this data into a standardized format that the receiving application can interpret.

For instance, consider two systems where one uses Big Endian byte ordering (the most significant byte is stored first) and the other uses Little Endian ordering (the least significant byte is stored first). The Presentation Layer converts data between these formats to ensure it is interpreted correctly by the receiver.

Similarly, image formats (e.g., JPEG, PNG) or file formats (e.g., PDF, DOC) may be encoded differently on various systems. The Presentation Layer ensures that these formats are properly translated between sender and receiver to maintain data integrity.

Data Encryption and Decryption

The encryption and decryption of data are essential for securing sensitive information in transit. The Presentation Layer provides the functionality needed to encrypt data before it is sent over the network and decrypt it upon receipt.

For example, in a secure banking transaction over the internet, the data transferred between the user and the bank’s server must be encrypted to prevent eavesdropping or unauthorized access. Secure Socket Layer (SSL) and Transport Layer Security (TLS) protocols operate at this level to secure communications.

Encryption involves converting readable data (plaintext) into an unreadable format (ciphertext) using an encryption key. When the data reaches its destination, the Presentation Layer uses a decryption key to convert the ciphertext back into plaintext, making it readable again.

Data Compression and Decompression

Data compression is a technique used by the Presentation Layer to reduce the size of the data being transmitted, thereby optimizing bandwidth usage and speeding up data transfer. By compressing data, the layer ensures that more information can be sent across the network in less time.

For instance, when transferring large files such as images, videos, or software, compression algorithms like ZIP or GZIP are applied to minimize file size. At the receiving end, the data is decompressed by the Presentation Layer to restore it to its original size.

Compression helps improve network performance by reducing congestion and making the most of available bandwidth, especially in scenarios where bandwidth is limited or expensive.

Character Encoding and Syntax Conversion

Character encoding is another key responsibility of the Presentation Layer. Since different systems may use different encoding standards, such as ASCII , Unicode , or EBCDIC , the Presentation Layer ensures that the data is properly converted so that it can be correctly interpreted by the receiver.

For example, if a sender uses ASCII encoding for a text file but the receiver uses Unicode, the Presentation Layer converts the ASCII-encoded characters into Unicode format to ensure that the text is correctly displayed on the receiving end.

Similarly, the Presentation Layer handles syntax conversion , ensuring that the data structures or data types used by the sending application are properly converted into a format that the receiving application can process. This is particularly important when exchanging data between systems that may use different file formats, data representations, or programming languages.

Protocols Operating at the Presentation Layer

Several protocols and formats operate at the Presentation Layer, helping to manage data translation, encryption, and compression. Some of the most widely used include:

• SSL (Secure Sockets Layer) / TLS (Transport Layer Security): These protocols provide encryption and secure data transmission over the internet, commonly used in web browsers and secure online transactions.
• JPEG, PNG, GIF: These image formats are handled at the Presentation Layer to ensure that images are properly encoded and displayed.
• MIME (Multipurpose Internet Mail Extensions): MIME is used to encode binary data for transmission in email attachments. It converts binary data into a text-based format that can be sent through email systems.
• XDR (External Data Representation): XDR is a standard for the description and encoding of data that is used for data exchange between different platforms.
• ASCII and EBCDIC: Character encoding standards that are often converted by the Presentation Layer to ensure cross-platform compatibility.

Role of the Presentation Layer in the OSI Model

The Presentation Layer serves as the intermediary between the Application Layer (which is closest to the end user) and the lower layers that manage network functionality. It translates, encrypts, compresses, and formats data so that it can be successfully transmitted and understood by different systems.

While the Transport Layer ensures reliable delivery of data, the Presentation Layer focuses on ensuring that the data itself is in the correct format and structure for the receiving system. Without the Presentation Layer, data could become corrupted, unreadable, or incompatible between systems with different architectures or formats.

Use Cases of the Presentation Layer

The Presentation Layer plays a vital role in many everyday network activities and services. Some of the most common use cases include:

• Secure Web Browsing: When a user visits a secure website (e.g., one using HTTPS), the Presentation Layer ensures that all data exchanged between the browser and server is encrypted via SSL/TLS protocols.
• File Compression for Transmission: Before sending large files over a network, the Presentation Layer compresses the data to optimize bandwidth usage, ensuring faster transmission speeds.
• Email Attachments: When attaching files to emails, the Presentation Layer encodes the file data using MIME, ensuring it can be correctly transmitted and decoded by the recipient’s email client.
• Multimedia Applications: In multimedia applications such as video streaming or image sharing, the Presentation Layer handles the compression and formatting of video, audio, and image files to ensure they are displayed correctly on the receiver’s device.
• Cross-Platform Data Sharing: The Presentation Layer enables different systems (e.g., a Windows machine and a Unix server) to share data by converting it into a format that is compatible with both systems.

Benefits of the Presentation Layer

The Presentation Layer provides numerous benefits that are essential to network communication:

• Data Compatibility: It ensures that data exchanged between different systems is compatible, regardless of differences in data formats or encoding schemes.
• Data Security: Through encryption and decryption, the Presentation Layer protects sensitive information during transmission, ensuring confidentiality and security.
• Bandwidth Optimization: Data compression reduces file sizes, allowing for more efficient use of bandwidth and faster transmission times.
• Cross-Platform Communication: It handles character encoding and syntax conversion, enabling different systems with varying architectures to communicate seamlessly.
• Ensures Data Integrity: By translating and formatting data, the Presentation Layer helps prevent data corruption or misinterpretation between sender and receiver.

Challenges of the Presentation Layer

Despite its benefits, the Presentation Layer faces several challenges:

• Complexity in Data Translation: Handling multiple data formats and character encodings can add complexity, especially when ensuring compatibility across different systems and applications.
• Processing Overhead: Encryption, compression, and decompression processes can introduce overhead, increasing the time it takes to process and transmit data.
• Security Vulnerabilities: While the Presentation Layer manages encryption, any flaws in its implementation (e.g., outdated SSL/TLS versions) can leave data vulnerable to attacks.

Frequently Asked Questions Related to the Presentation Layer

What is the role of the presentation layer in the osi model.

The Presentation Layer is responsible for translating, encrypting, and formatting data to ensure it can be properly interpreted by the receiving application. It handles data compression, encryption, and syntax conversion to enable communication between different systems.

How does the Presentation Layer handle data encryption and decryption?

The Presentation Layer encrypts data before it is sent across a network to ensure secure transmission. Upon arrival, the layer decrypts the data so that the receiving application can read it. Encryption protocols like SSL/TLS operate at this layer to ensure data privacy.

What are the key functions of the Presentation Layer?

The key functions of the Presentation Layer include data translation, encryption/decryption, data compression, and character encoding conversion. It ensures that data from the application layer is properly formatted before being transmitted over the network.

Which protocols operate at the Presentation Layer?

Common protocols and formats that operate at the Presentation Layer include SSL/TLS for encryption, JPEG and PNG for image compression, and MIME for encoding email attachments. These protocols ensure that data is properly formatted and secure during transmission.

How does data compression work at the Presentation Layer?

The Presentation Layer compresses data before it is transmitted to reduce file sizes and optimize bandwidth usage. Upon reaching the destination, the data is decompressed to its original format. This helps speed up data transmission and improve network performance.

Related Blogs on the OSI Model

• What is the OSI Model?
• What Is the Physical Layer in the OSI Model?
• What Is the Data Link Layer in the OSI Model?
• What Is the Network Layer in the OSI Model?
• What Is the Transport Layer in the OSI Model?
• What Is the Session Layer in the OSI Model?
• What Is the Application Layer in the OSI Model?

Click the Copy to Clipboard button and paste into your web page to automatically add this blog content to your website

Content Copyright(c) 2024, ITU Online, LLC. Permission is granted to embed but not copy content in this blog. ITU Online, LLC reserves the right to modify or remove this content at any time.

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.

$ 699.00 Original price was: $699.00. $ 299.00 Current price is: $299.00.

$ 199.00 Original price was: $199.00. $ 129.00 Current price is: $129.00.

$ 49.99 Original price was: $49.99. $ 16.99 Current price is: $16.99. / month with a 10-day free trial

Start for only $1.  Unlock endless learning opportunities with over 2,600 hours of IT training at our lowest price ever. Plus, get all new and updated online courses for free while your subscription remains active.

Cancel at your convenience.  This exceptional deal on IT training provides you access to high-quality IT education at the lowest monthly subscription rate in the market.  Boost your IT skills and join our journey towards a smarter tomorrow.

• Monday - Friday: 9am - 5pm ET
• Office: +1 855.488.5327

SHOPPING CART

Information

• IT Glossary
• Quick Byte Answers
• Our Instructors
• Privacy Policy
• Career Paths

Business Solutions

• Reseller Opportunities
• Team Training
• Affiliate Opportunities
• Student Login

Get 1 full year of access to every course, over 2,600 hours of focused learning for only $79.00 . 

today Only: here's $50.00 Off

Get 1-year full access to every course, over 2,600 hours of focused IT training, 21,000+ practice questions at an incredible price.

Learn CompTIA, Cisco, Microsoft, AI, Project Management & More...

Simply add to cart to get your $50.00 off today!

• What are some good and bad practices writing code comments
• How to fix “vc_runtimeMinimum_x64.msi is missing” error
• My old sticky note or how to be a better software developer

CAP theorem explained

• HTTP for beginner programmers
• Three ways to become a better developer

Strategy pattern. A design pattern we use every day

Design patterns explained. what do we benefit from design patterns, layered architecture. what is layered architecture and when to use it.

Layered architecture is the first architectural pattern that we are going to explore. If you haven’t read my article about software architecture , I suggest you do it before continuing with this one.

What is a layered architecture?

Simply put, the layered architecture pattern ‘s main idea is to group and isolate system concerns while defining strict communication direction between them.

Each group of related modules/classes we call layer. Different layers are encapsulated and depend on each other through abstraction and well-defined interfaces.

Layers in this architecture pattern are stacked. The request direction is from the upper layers to the lower layers. In the best-case scenario, a layer can request a layer that is only directly below it.

In sporadic cases, an upper layer is allowed to request a layer two-level or more levels below, but in general, it is considered bad practice.

Layered architecture is widespread. We can find it the simple client->server pattern or OSI network model . Also, many enterprise applications implement that pattern.

*In the following examples, we do not discuss cross-cutting concerns and their implementation.

What is the difference between layered architecture and N-tier architecture?

There is none significant one. By tier, we consider a physical layer (like SQL server, for example). N describes the number of layers/tiers you have.

In general, both names refer to the principles we discuss in this article.

Enterprise application example

Most of the layered architecture implementations consist of four layers (ok, three layers, and a tier).

Presentation layer

Business layer.

• Data Access layer
• Data Storage tier

Their names are explanatory enough, but let’s discuss them in detail.

In the presentation layer, you can find user interface components.

In a standard ASP.NET Core application, these are the Views. The presentation layer, of course, is not limited to any technology. You can have anything that a user can interact with. CLI, SPA, etc.

The presentation layer should not contain business logic and should not access database data directly.

Its only task is to visualize data and dispatch the user’s input. That’s why the presentation layer requests data and sends commands from/to the business layer.

The business layer is where your core business logic lives. Here you can find modules and services (classes) specific to the business domain operations. Operations like calculating discounts, rearranging schedules, etc.

If data is needed, the business layer requests it from the data access layer.

When returning a result to the presentation layer, the business layer should not apply any data formatting. As we understood from the above paragraphs, this responsibility is entirely for the representation layer.

Data access layer

The data access layer or persistence layer’s main task is to communicate (query and persist data) from/to the data storage (SQL DB, NoSQL, flat files, etc.).

The most common data access layer translates requests to SQL queries and sends them to the SQL Server via data access objects (DAOs). In most cases, these DAOs implement a Repository pattern.

The data access layer also implements transaction capability (often through a Unit of work pattern).  You can also find a Unit of work implemented in the business layer in some cases, but this is wrong.

Data Storage

I intentionally don’t say database because your storage could be anything—even CSV files. Of course, no sane man will do that.

You should not put any logic in this tier. Ideally, you should use it only for storage.

Structure of layered architecture

In a layered application, the structure is quite simple.

The example I am giving you is with MS stack, but technology does not change the principles we should follow.

Also, you will see that we have three logical layers and three tiers.

Consider the example set up at on-premises infrastructure, not in the cloud.

On a separate machine (tier 1) with IIS, we have a standard ASP.NET Core application. This is the presentation layer.

One level below (tier 2), we find an IIS on a separate server. On it, there is deployed a Web API application.

In the Web API application, we can see a very thin layer of REST APIs (implemented through Web API controllers), the business layer, and the data access layer.

The primary responsibility of the APIs controllers is to route a request to the business layer, so we don’t consider them important enough to classify them as a separate layer,

Controllers, business layer, and data access layers are isolated. They live in different projects and reference each other only through interfaces . We use dependency injection for instantiating services.

At the bottom (tier 3), we have a machine with an operational database managed by MS SQL Server.

In the past, most of the applications didn’t split their logical layers over different tiers (except the data storage tier). We do this to increase isolation, flexibility (to some extent), and ease of deployability.

Scale-out benefits are limited due to the monolithic nature of the architecture.

Flow of layered architecture

What happens when, for example, a user searches for a product (if we consider our application is an eCommerce website)?

The ASP.NET Core application UI requests the Web API specific REST API.

The API controller instantiates a service object from the business layer and requests the search through a specific method.

On its behalf, the business layer instantiates a data access object (or several) from the data access layer and calls a specific method/s.

The data access object translates the request to a SQL query and sends it to the SQL Server. 

SQL Server returns the result. The data access object returns the result in the form of data transfer object/s to the business service. 

Suppose any transformation or logic is needed (like calculation discount, as we said earlier). In that case, the business service transforms the data based on the business logic and returns it to the Web API controller.

The Web API controller returns an HTTP response to the ASP.NET Core application.

ASP.NET Core application receives the data formats it and shows it to the user.

When to use layered architecture?

Layered architecture is a great pattern, but it comes with its advantages and limitations like any other tool.

If you need a highly scalable solution, this architecture is not for you. The monolithic nature of the pattern prevents you from scaling out different components or services.

Another drawback of the pattern is its lack of agility. Even with good isolation of horizontal layers, it is a matter of time for the internal components to become “chatty” and form coupled dependencies.

And of course, this affects the deployment process. In most cases, even with different tier separation, it is all or nothing.

Or you don’t need a layered architecture at all. If most of your business layer’s services only redirect requests from the UI to the data access layer and return data, this implementation would be overkill.

Layered architecture is a very developer-friendly pattern. Even if your dev team does not have enough experience , following this pattern won’t be hard.

The pattern is also widely used and recognized among developers, so a new joining member can quickly become productive.

Separation of concerns helps for concurrent work over functionalities. It is common to see front-end developers working on the UI while back-end developers develop business services logic and data access functionalities.

Another great plus is testing. Having layers separated is a lot easier to mock them and test in isolation.

If your application does not need to scale out, and the business logic is not very complex, the layered architecture is an excellent choice for rapid development and delivery.

A long time ago, I read that layered architecture is like lasagna (with its layers), and it is better to have lasagna for lunch instead of spaghetti :).  I can not agree more.

But In my next article, we are going to add the onion. Yes, the following architecture pattern is Clean architecture , also called Port and adapters or Onion architecture.

Good books to read: Software architecture in practice 3rd edition

Overengineering. Predicting the future does not work

Related posts.

Write A Comment Cancel Reply

Save my name, email, and website in this browser for the next time I comment.

Type above and press Enter to search. Press Esc to cancel.

A Guide To 3-Tier Architecture

A well-structured and organized solution is crucial for maintainability and scalability in software development. The 3-Tier architecture clarifies concerns, allowing developers to manage the application logic, data access, and presentation layers separately. In this article, we will explore the benefits of this architecture and learn how to implement it in a Visual Studio solution using C#. 

Different Architectures

There are many types of architectures you can use for your applications. You just have to find the one that suits your needs. I like the 3-tier architecture. It’s small, simple, and easy to create. But in some cases, I might change it because of my needs.

There are 9 known architectures we use these days in C#:

• Monolithic architecture
• Microservices architecture
• 3-tier architecture
• Model-View-Controller (MVC) architecture
• Model-View-Presenter (MVP) architecture
• Model-View-ViewModel (MVVM) architecture
• Event-Driven architecture
• Service-Oriented Architecture (SOA)
• Client-Server architecture

I am not going to explain them all. It will become a very large page. But the top 3 popular architectures are:

• Microservices architecture A way to break down a large and complex application into smaller, independent services that are connected. They communicate with each other through APIs. This architecture is becoming popular with bigger projects. You can maintain and deploy the smaller projects more easily.
• 3-tier architecture This type of architecture separates an application into three logical components: the presentation layer, the application layer, and the data layer. This separation of concerns provides better scalability, maintainability, and ease of development.
• Model-View-Controller (MVC) architecture  Well-known if you have created web applications and/or  APIs  with C#. It is a design that separates the application logic from the user interface. The Model component represents the data and the business logic, the View component displays the data, and the Controller component handles user input and updates the Model. This separation of concerns provides a more organized and maintainable codebase.

This tutorial explains the 3-tier architecture mainly because we use this one the most.

The 3-Tier Architecture

This architecture separates the application into three logical components. These three layers help to maintain the code and separation of concern. But for me, it has a different reason I use this architecture: reusability. 

Especially at a time when you might want to create a Windows, macOS, Android, Linux, and iOS app that does the same thing. Do you create the same class over and over again? No, you create a class library with the logic and reference that library in all the projects that need the logic. If something changes in the class library, all other projects get updated.

Three Different Layers

Each layer has its own responsibility but only talks to one other layer. The presentation layer only talks to the application layer and the application layer only talks to the data layer. That means that if you want to show a list of movies, for example, you need to ask the application layer which will ask the data layer. The application layer will send the information of the data layer to the presentation layer. The presentation layer never talks to the data layer directly.

The Data Layer

The first layer I am discussing is the data layer. Maybe the name already tells you what this layer is about: Data. It could be data from a database or a file. Generally speaking, we use this layer to transport data from and to a data source.

This layer does not contain any form of logic. It just sends or retrieves data from the data source. Nothing special. Logic is placed in the application layer.

If you have multiple data sources you need to manage, you can create multiple data layers and bring them together in the application by using dependency injection.

The data layer is a layer that is disappearing a bit. Before we had ORMs, like  Entity Framework , we had to write a lot of code to retrieve and send data from and to a database. With Entity Framework, we don’t need that anymore. That is the reason the logic for the database is moving to the application layer.

The Application Layer

This layer is the beating heart for all your logic. Here you combine logic with the data from the data layer. This layer is responsible for calculations and decisions before sending the data to your presentation layer.

The application layer is often called the business layer. This is a small heritage from the time we had the DLL (data layer library) and the BLL (business layer library). In my projects, I usually call it the business.

For example, the presentation layer requests a list of movies, ordered by title. The application layer will retrieve all the movies from the data layer and sort them by title.

This layer does nothing with the data source directly. The reason is simple: The application layer should never know what kind of data source you use. If you implement dependency injection, the data source can change. Even the whole data layer can change (except for the interface). But the application layer should always be working without changing it.

You can have multiple application layers. I created a logger once. A simple logger that stores messages in a file. But later I needed a logger that stored the messages in a database. I didn’t want two loggers in the single class library representing my application layer. So I created a second application layer for the logger.

It’s usually this layer we  unit test  because it contains the most important code of our application.

The Presentation Layer

And last but not least; the presentation layer. This layer is what a user sees. It could be a console application, WinForms, or an API. It’s the one that gives output that a user or a client application can work with. This layer is also referred to as the top-most layer in this architecture.

It is responsible for presenting the data from the application layer in a user-friendly way. Examples of user-friendly are web pages, WinForms, and mobile apps.

A console application or a WinForms application has a clear GUI. You can click on stuff and it works. An API doesn’t have that. But it does expose JSON (or XML if you want). An API is considered a front-end application.

Conclusion On A Guide to 3-Tier Architecture

The 3-tier architecture is the most used because it’s easy to understand and implement. I encourage you to use this if you just start or create a small project. If you have a really, really small project; make your life easier, and don’t use layers.

The idea behind these layers is to separate data, logic, and application. I think the names are a bit confusing and most people think the application layer is the front end, but that’s the presentation layer. And that is why I call the application layer the business layer.

Related Articles

Learn C# Essentials and Frameworks for New Developers

Learn C# – Part 9: Basic Structure And A New Project

Kenji Elzerman

After many years of being a software developer I made a change and I became a C# teacher for people with ADHD and autism. One of the most rewarding jobs I ever had. I developed my sense for teaching and I discovered I love the knowledge transfer. But traveling called and I couldn't sustain my job while traveling. So I started kenslearningcurve.com. A website and a place where people can learn C# and everything that comes with it. I try to avoid the "give me more money so I give you something" and create content that really matters. I strive to create quality for you. Besides owning this website I am also the creator and write of Entity Framework Core , where you can learn Entity Framework Core from A to Z.

ChatGPT: Yay or nay?

10 reasons why you should unit test, you may also like, visual studio shortcuts, design patterns and design principles, to savechanges or not to savechanges, top 5 reasons to use c#, how to apply clean code with c#, the c# data types part 2 – int, the c# data types part 1 – string, the use of code comments.

• Online Courses

Free Tutorials

C# Bootcamp

• Kens Learning Curve
• Kens Learning Paths
• Technical Writer
• Career Advise

Kens Learning Curve is all about learning C# and all that comes along with it. From short, practical tutorials to learning from A to Z.

All subjects are tried and used by myself and I don’t use ChatGPT to write the texts.

Useful links

Use the contact form to contact me or send me an e-mail.

The contact form can be found here .

Email: [email protected]

@2023 – All Right Reserved. Designed and Developed by Kens Learning Curve

Web Application Architecture: How the Web Works

• Engineering
• Published: 25 Jul, 2019
• No comments Share

When building a web application, there are three main principles to bear in mind. From a customer’s point of view, the application should be simple, aesthetically pleasing, and address most of their problems. From the business aspect, a web application should stay aligned with its product/market fit . From a software engineer’s perspective, a web application should be scalable, functional, and able to withstand high traffic loads. All these issues are addressed in the web application’s architecture. We’ll cover the basic concepts of any modern web application and explain how the architecture patterns may differ depending on the application you’re building.

What is Web Application Architecture?

So, what is a web application, and how is it different from a website? The basic definition of a web application is a program that runs on a browser. It’s not a website, but the line between the two is fuzzy. To differentiate a web application from a website, remember these three formal characteristics. A web application:

• addresses a particular problem, even if it’s simply finding some information
• is as interactive as a desktop application
• has a Content Management System

A website is traditionally understood to simply be a combination of static pages. But today, most websites consist of both static and dynamic pages, which makes almost all modern websites - you guessed it! - web applications. In this article, we will use the terms interchangeably. Your computer, or smartphone, or any other device you’re browsing with is called a client. The other half of the web equation is called a server because it serves you the data you request. Their communication is called a client-server model, whose main concern is receiving your request and delivering the response back. Web application architecture is a mechanism that determines how application components communicate with each other. Or, in other words, the way the client and the server are connected is established by web application architecture. Web applications of different sizes and complexity levels all follow the same architectural principle, but details may differ. We will further explain how a basic request-response process works and what components comprise the architecture.

How does the web request work?

Web request-response cycle

Let’s look at Amazon.com to illustrate our explanation. First, you visit amazon.com . You type in the URL and as you hit Enter, your browser prepares to recognize this URL, because it needs to know the address of the server where the page is located. So it sends your request to the Domain Name Center (DNS), a repository of domain names and their IP addresses. If you've already visited Amazon from the same browser, it will pull the address from the cache. Then, a browser sends the request to the found IP address using the HTTPS protocol. Second, the web server processes the request . The web server where Amazon.com is located catches the request and sends it to the storage area to locate the page and all data that follows with it. But its route is held via Business Logic (also called Domain Logic and Application Logic). BL manages how each piece of data is accessed and determines this workflow specifically for each application . As BL processes the request, it sends it to storage to locate the looked-for data. Third, you receive your data . Your response travels back to you and you see the content of the web page on your display. The graphical interface you see when scrolling Amazon's or any other website is called the front end of an application - it depicts all UX and UI components so that a user can access the information they came looking for.

Web application architecture components and Three-Tier Architecture

Web application architecture following the three-tier pattern

Presentation layer

The presentation layer is accessible to users via a browser and consists of user interface components and UI process components that support interaction with the system. It’s developed using three core technologies: HTML, CSS, and JavaScript. While HTML is the code that determines what your website will contain, CSS controls how it will look. JavaScript and its frameworks make your website interactive - responsive to a user’s actions. Developers use JavaScript frameworks such as Angular and React to make the content on the page dynamic.

Business layer

This layer, also called Business Logic or Domain Logic or Application Layer, accepts user requests from the browser, processes them, and determines the routes through which the data will be accessed. The workflows by which the data and requests travel through the back end are encoded in a business layer. For example, if your application is a hotel booking website, business logic will be responsible for the sequence of events a traveler will go through when booking a room. Although business rules can be a manifestation of the business logic, they are not the same. Sometimes business rules are extracted and managed separately, using a Business Rules Management System, as we discussed in our article on back office systems .

Persistence layer

Also called the storage or data access layer, the persistance layer is a centralized location that receives all data calls and provides access to the persistent storage of an application. The persistence layer is closely connected to the business layer, so the logic knows which database to talk to and the data retrieving process is more optimized. The data storage infrastructure includes a server and a Database Management System , software to communicate with the database itself, applications, and user interfaces to obtain data and parse it. Typically you can store your data either in owned hardware servers or in the cloud - meaning, that you purchase data center management and maintenance services while accessing your storage virtually. Using the services of cloud technology providers such as Amazon, Google, or Microsoft, you can utilize Infrastructure-as-a-Service, Platform-as-a-Service, or serverless approaches to cloud management. There are also components that usually exist in all web applications but are separated from the main layers: Cross-cutting code. This component handles other application concerns such as communications, operational management, and security. It affects all parts of the system but should never mix with them. Third-party integrations . Payment gateways, social logins, GDSs in travel websites are all integrations connected to the application’s back end via pieces of code called APIs. They allow your software to source data from other software and widen your functionality without coding it from scratch. Read how APIs work in our dedicated article. Let’s see how the three-tier architecture is implemented in different types of web applications.

Example #1. Dynamic web pages, SPAs, and MPAs

The application’s front end can serve either static or dynamic content. In most cases, it’s a combination of both. Static Web Pages exist on a server as they are and contain information that doesn’t change. Dynamic Web Pages change information every day or in response to a user’s request - think of any news website or your Twitter feed. The combination of dynamic and static content makes up a web application. The simplest example of a web application with dynamic content is a Single Page Application.

Single Page Applications

Single Page Application architecture

When the role of the server is reduced to data services, this is sometimes called thin server architecture. We can’t talk about SPAs without mentioning the more traditional model - Multi-Page Applications.

Multi-Page Applications

MPA architecture

As opposed to the SPA’s client-side scripting, traditional applications are written using both client- and server-side languages. Server-side scripting means that all operations are performed on the server’s end, so when you request content, it processes the script, retrieves data from the storage and chooses the content to display. Server-scripting languages you should be familiar with include PHP, Java , Python, Ruby, C#, and more.

Example #2. Enterprise applications

Enterprise application architecture

Apart from an extra layer, enterprise applications have access to data sources from other applications in an organization, making it a network of software solutions, connected by APIs. Besides, there are more groups of users who have access to different functional components - they can be business partners, clients, admins, and several groups of staff. Sometimes the presentation tiers are separate for all of them, so you can deploy the application as intranet or extranet.

To conclude

This, hopefully, sheds some light on the backstage of building modern websites. In this article, we dipped our toes into the complicated subject of software engineering. If this wasn’t enough for you, feel free to roam around our blog a bit more and specifically explore the following articles. The Good and the Bad of JavaScript Full Stack Development Technical Documentation in Software Development: Types, Best Practices, and Tools How to Use Open Source Software: Features, Main Software Types, and Selection Advice

Stack Exchange Network

Stack Exchange network consists of 183 Q&A communities including Stack Overflow , the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Is validation part of presentation layer or business logic? [duplicate]

We're working on a new project (backend, API), following the "clean code" and "clean architecture" principles (described in Robert Martin's books), dividing our application into presentation, domain, and data layers. The presentation layer handles routes and data formatting, while the domain layer contains the business logic and accesses data when needed.

We're debating whether data validation should occur in the presentation layer (to validate user input directly) or the domain layer (as part of business logic). I'm convinced it belongs to presentation, since we want to validate raw user input and provide hints what's wrong, and if we do it in domain layer we may be dealing with transformed data that's vastly different from user input, hence we can't give clear hints on what should be fixed. My colleagues however maintain validation is part of business logic and should be part of the domain layer.

By validation I mean checks like "value is integer and in range from 1 to 100" or "string matches this format".

Can anyone clarify which approach is the best and recommend references for further understanding this issue?

• domain-driven-design
• clean-architecture

• See also softwareengineering.stackexchange.com/a/348916 . Or in short, the answer it is part of both. –  Doc Brown Commented Feb 8 at 23:12
• I would recommend thinking about where you draw the system boundary. On the outside of that boundary, data is untrusted and may be invalid, often in form of DTOs. Internally, you want to rely on the data being valid, often in form of meaningful objects. So that boundary must perform validation+conversion and reject illegal inputs. In web applications, the client cannot be trusted so that boundary is necessarily in the backend, but the part in the backend where validation happens might not yet be the core "business logic". Any frontend validation is just for UX, not for correctness. –  amon Commented Feb 8 at 23:36
• 1 Please see this answer –  John Wu Commented Feb 9 at 1:31

4 Answers 4

It's an unfortunate fact that the same validation rules often have to be applied and checked repeatedly at different places in the same application.

The validation rules themselves may often be identical, but the reaction to invalid input will not necessarily be the same in each place, and the timing of the enforcement will not necessarily be the same.

For example, as you say, validation rules often have to exist at the presentation layer in order to give immediate feedback to the computer user, and to allow everyday input errors to be corrected. There may be logic that is specific to the presentation layer, such as highlighting erroneous fields, help text which explains acceptable ranges of input, and so on.

However, some kinds of rule may also be inherently enforced at deeper layers. For example, certain fields may have length limits at the storage layer.

For technical reasons, constraints defined at the storage level are often considered the primary or originating constraint, and any duplication of the constraint that exists at the presentation layer is merely an auxiliary or slave version of the same constraint.

What I'm trying to say is that the primary site of enforcement for different constraints can be intrinsically more local to one layer or another, so that it isn't possible to set out with the idea of simply placing all constraints merely in one layer.

However, for reasons of application responsiveness, to ensure that the user is given an opportunity to fix or react to violations as soon as possible, to avoid part-triggering a heavyweight process that will subsequently crash out, or just to try and ensure there is at least one place in source code where a consolidated view of all the constraints is available, it may be considered desirable to have auxiliary and pre-emptory enforcement of constraints at the presentation layer, and the primary constraint at a deeper layer would be triggered only as a backstop when developer error meant the auxiliary/pre-emptory constraint was not properly applied.

And because the hitting of the primary constraint now implies developer error, the programmed reaction of the application may be very different (and involve the alerting of system supervisors) than when only the auxiliary constraints are hit in the presentation layer (which are likely considered normal and lead only to normal user feedback). So even though the criteria for the constraints are the same, the reaction isn't.

Because we now have this concept of primary and auxiliary sites at which constraints are enforced, and because of the possibility of developer error in synchronising the auxiliary constraints with the primary ones, and perhaps for additional architectural reasons, there can often end up being even more than two enforcement sites for the same constraint. There can be a primary site and also multiple auxiliary sites.

And although above I have given an example of the primary site for a constraint being in the storage layer, in some cases, the primary site for a constraint may not even be in the computer system under development, or even originate in the same organisation. For example, the constraint may originate in the law of the land, or in the bureaucratic rules of a different organisation. So even if there was only one site of enforcement in your source code, there may still be additional sites outside the source code in question, and those outside enforcement sites may in fact be the primary enforcement sites which your source code has to reflect (and pre-empt).

For any kind of business information system, it isn't generally possible to avoid having multiple representations of constraints and multiple sites of enforcement in source code, the synchronisation of which has to be handled manually by the developers.

Rather than thinking of this as a wasteful kind of redundancy that can be driven out by better design, consider that each site of enforcement is often encountered at a different time in an overall schedule of processing, and there may be different programmed consequences of a violation being detected at different sites even though the criteria for the violation itself is essentially the same.

You're getting sidetracked by thinking of validation as a single indivisible concept and assuming that it must belong to one specific location.

The truth is that different kinds of validation exist, and different validations belong in different places. Just some quick examples:

• If we want to block people under 18 from renting certain books, that's a business rule, and therefore it belongs to the application layer (or domain, for the purpose of this example domain/application is context-dependent)
• Did the incoming API request contain correct parameter values (e.g. making sure an int parameter is not "banana" )? That's endpoint validation and belongs in the API layer.
• Does this string value contain any encoded characters that the persistence store can't handle? This is the kind of validation that you'd put in the persistence layer.
• Do we want to give the user immediate feedback about their input before they try to submit the form? That would require validation rules to be executed in the frontend. That kind of validation would inherently need to live in the frontend (unless you are okay with polling the BE for validation, which is not particularly efficient)

Like so many things, this isn't a predetermined answer that you can find online and then apply in your codebase. This is something that needs you to consider your own specific use case and find what works best for you .

By validation I mean checks like "value is integer and in range from 1 to 100" or "string matches this format"

These do sound to me like they're business rules, so the application layer is definitely a correct place for them.

Then there's the question of whether you want to also bake validation into the frontend. The benefit of doing so would be that you can provide the user immediate feedback instead of waiting for them to submit the form. The drawback is that you have to develop the same validation a second time (and usually you can't reuse logic between FE/BE as they tend to use different languages).

I strongly advise you don't take a FE-only validation approach, because FE-only validation can be circumvented by a malicious user who knows how to use their browser's dev tools or craft their own requests (e.g. using PostMan). That being said, if malevolent use does not cause a problem for anyone except the user themselves, you can argue that you don't need to defend against malevolent use. But that is a dangerous call to make if you're wrong.

• Thanks for your reply! By presentation layer as I said in the question I meant not frontend, but the layer of backend API where requests are received, decoded, passed to business logic layer and then formatting response –  LNK Commented Feb 9 at 10:31
• @LNK That's a reasonable ambiguity to point out but it's the same principle at play regardless –  Flater Commented Feb 11 at 9:15

If what you are doing is parsing some general purpose representation to ensure that it conforms to some schema, you will normally want that to happen as close to the process boundary as you can conveniently manage.

If what you are doing is comparing the information to some current policy, or performing a comparison of that information to other information that has already been collected (ie: what's in the database), then that will normally be a domain model concern.

Example: some field in the input message is supposed to be RFC 4122 compliant UUID ? That's a parsing concern that you put near the boundary. The UUID is supposed to match one of the known productId values in our system? That's a domain model concern.

If I could look back at one thing that improved my take on validation the most, it’s adherence to a closure of operations. I’d encourage you to go back to those sections on command/query separation and closure of operations in the Big Blue Book. Once I adhered to those two concepts, validation was merely another step in reporting the success or failure of an operation, and like many good simplifications, a host of symptoms I mistook for separate diseases just went away. -- Jimmy Bogard, 2009

Short answer: Both!

This is what we used to call Defensive Programming. Checking that that the Data we've being given will "fit" into wherever we need to put that Data next and rejecting it if it doesn't.

At the Business level, we need to ensure that, say, a Transaction amount is numeric and has a "sensible" value, that a given UserId actually does exist in the backend system, that the Product whose Id we've been supplied actually exists and we've got enough of them to meet this order.

At the Presentation level, it's "nice" to check all of these things and give "immediate" feedback where we can and, indeed, most modern users would expect us to do just that. But that's for their benefit, as part of the User Experience, not ours , as part of our protecting our systems against duff Data.

In the world of the Web Application, nothing from the client should be trusted. All the JavaScript (or whatever) validation code in the World can now be "edited away" by a sufficiently-determined user, armed with nothing more than their web browser. Question: If you send an HTML SELECT list to the User to choose an option from, do you validate the value that comes back? You should ...

Not the answer you're looking for? Browse other questions tagged domain-driven-design validation clean-architecture or ask your own question .

• The Overflow Blog
• Where developers feel AI coding tools are working—and where they’re missing...
• He sold his first company for billions. Now he’s building a better developer...
• Featured on Meta
• User activation: Learnings and opportunities
• Preventing unauthorized automated access to the network

Hot Network Questions

• What made scientists think that chemistry is reducible to physics and when did that happen?
• Why does Voyager use consumable hydrazine instead of reaction wheels that only rotate when moving the spacecraft?
• Does a ball fit in a pipe if they are exactly the same diameter?
• Soldering a thermal fuse. 92°C
• The meaning(s) of 'She couldn't buy a car yesterday.'
• Does the old type of rubber hose Dunlop valves haves any pros compared to the modern ones without rubber?
• I want a smooth orthogonalization process
• Pulling myself up with a pulley attached to myself
• How do Cultivator Colossus and bounce lands interact?
• Cost of Laos visa
• How long has given package been deferred due to phasing?
• What is the mechanical equivalent of an electronic AND gate?
• How was the year spoken in late 1800s England?
• cURL in bash script reads $HOME as /root/
• If a professor wants to hire a student themselves, how can they write a letter of recommendation for other universities?
• "Chrisma" and "Him"
• Day Convolution of Sheaves
• How important exactly is the Base Attack Bonus?
• Lovecraftian (but not written by Lovecraft himself) horror story featuring a body of water that glowed blue at night due to the creatures in it
• Tic-tac-toe encode them all
• How can moving observer explain non-simultaneity?
• How to Vertically Stack Multiple Plots with Custom Color Functions and Opacity in Mathematica?
• Does legislation on transgender healthcare affect medical researchers?
• How to apply a function to specific rows of a matrix

NDepend Blog

Improve your .NET code quality with NDepend

Software Architecture: The 5 Patterns You Need to Know

Share this:.

When I was attending night school to become a programmer, I learned several design patterns : singleton, repository, factory, builder, decorator, etc. Design patterns give us a proven solution to existing and recurring problems. What I didn’t learn was that a similar mechanism exists on a higher level in the form of the software architecture pattern .

These are patterns for the overall layout of your application or applications. They all have advantages and disadvantages. And they all address specific issues.

In this post, we’ll take a look at 5 such patterns in detail.  For each software architecture pattern, this will include a description, its advantages, its disadvantages, and the situation for which it is ideal.  The patterns are as follows.

• The Layered Architectural Pattern
• The Microkernel Architectural Pattern
• The CQRS Architectural Pattern
• The Event Sourcing Architectural Pattern
• The Microservices Architectural Pattern

Download the NDepend trial for free and use dependency graphs to get a feel for what your software architecture really looks like.

1. The Layered Architectural Pattern

The layered pattern is probably one of the most well-known software architecture patterns.

Many developers use it, without really knowing its name. The idea is to split up your code into “layers”, where each layer has a certain responsibility and provides a service to a higher layer.

There isn’t a predefined number of layers, but these are the ones you see most often:

• Presentation or UI layer
• Application layer
• Business or domain layer
• Persistence or data access layer
• Database layer

The idea is that the user initiates a piece of code in the presentation layer by performing some action (e.g. clicking a button). The presentation layer then calls the underlying layer, i.e. the application layer.

Then we go into the business layer and finally, the persistence layer stores everything in the database. So higher layers are dependent upon and make calls to the lower layers.

You will see variations of this, depending on the complexity of the applications. Some applications might omit the application layer, while others add a caching layer.

It’s even possible to merge two layers into one. For example, the ActiveRecord pattern combines the business and persistence layers.

Layer Responsibility

As mentioned, each layer has its own responsibility.

The presentation layer contains the graphical design of the application, as well as any code to handle user interaction. You shouldn’t add logic that is not specific to the user interface in this layer.

The business layer is where you put the models and logic that is specific to the business problem you are trying to solve.

The application layer sits between the presentation layer and the business layer.

On the one hand, it provides an abstraction so that the presentation layer doesn’t need to know the business layer. In theory, you could change the technology stack of the presentation layer without changing anything else in your application (e.g. change from WinForms to WPF).

On the other hand, the application layer provides a place to put certain coordination logic that doesn’t fit in the business or presentation layer.

Finally, the persistence layer contains the code to access the database layer. The database layer is the underlying database technology (e.g. SQL Server, MongoDB). The persistence layer is the set of code to manipulate the database: SQL statements, connection details, etc.

• Most developers are familiar with this pattern.
• It provides an easy way of writing a well-organized and testable application .

Disadvantages

• It tends to lead to monolithic applications that are hard to split up afterward.
• Developers often find themselves writing a lot of code to pass through the different layers, without adding any value in these layers. If all you are doing is writing a simple CRUD application, the layered pattern might be overkill for you.
• Standard line-of-business apps that do more than just CRUD operations

2. The Microkernel Architectural Pattern

The microkernel pattern, or plug-in pattern, is useful when your application has a core set of responsibilities and a collection of interchangeable parts on the side. The microkernel will provide the entry point and the general flow of the application, without really knowing what the different plug-ins are doing.

An example is a task scheduler.

The microkernel could contain all the logic for scheduling and triggering tasks, while the plug-ins contain specific tasks. As long as the plug-ins adhere to a predefined API, the microkernel can trigger them without needing to know the implementation details.

Another example is a workflow. The implementation of a workflow contains concepts like the order of the different steps, evaluating the results of steps, deciding what the next step is, etc. The specific implementation of the steps is less important to the core code of the workflow.

• This pattern provides great flexibility and extensibility.
• Some implementations allow for adding plug-ins while the application is running.
• Microkernel and plug-ins can be developed by separate teams.
• It can be difficult to decide what belongs in the microkernel and what doesn’t.
• The predefined API might not be a good fit for future plug-ins.
• Applications that take data from different sources, transform that data and writes it to different destinations
• Workflow applications
• Task and job scheduling applications

3. The CQRS Architectural Pattern

CQRS is an acronym for Command and Query Responsibility Segregation . The central concept of this pattern is that an application has read operations and write operations that must be totally separated.

This also means that the model used for write operations (commands) will differ from the read models (queries). Furthermore, the data will be stored in different locations. In a relational database, this means there will be tables for the command model and tables for the read model. Some implementations even store the different models in totally different databases, e.g. SQL Server for the command model and MongoDB for the read model.

This pattern is often combined with event sourcing, which we’ll cover below.

How does it work exactly?

When the application needs to show data to the user, it can retrieve the read model by calling the read service, as shown below.

• Command models can focus on business logic and validation while read models can be tailored to specific scenarios.
• You can avoid complex queries (e.g. joins in SQL) which makes the reads more performant.
• Keeping the command and the read models in sync can become complex.
• Applications that expect a high amount of reads
• Applications with complex domains

4. The Event Sourcing Architectural Pattern

As I mentioned above, CQRS often goes hand in hand with event sourcing. This is a pattern where you don’t store the current state of your model in the database, but rather the events that happened to the model. So when the name of a customer changes, you won’t store the value in a “Name” column. You will store a “NameChanged” event with the new value (and possibly the old one too).

When you need to retrieve a model, you retrieve all its stored events and reapply them on a new object. We call this rehydrating an object.

A real-life analogy of event sourcing is accounting. When you add an expense, you don’t change the value of the total. In accounting, a new line is added with the operation to be performed.

If an error was made, you simply add a new line. To make your life easier, you could calculate the total every time you add a line. This total can be regarded as the read model. The example below should make it more clear.

You can see that we made an error when adding Invoice 201805. Instead of changing the line, we added two new lines: first, one to cancel the wrong line, then a new and correct line.

This is how event sourcing works. You never remove events, because they have undeniably happened in the past. To correct situations, we add new events.

Also, note how we have a cell with the total value. This is simply a sum of all values in the cells above. In Excel, it automatically updates so you could say it synchronizes with the other cells. It is the read model, providing an easy view for the user.

Event sourcing is often combined with CQRS because rehydrating an object can have a performance impact, especially when there are a lot of events for the instance. A fast read model can significantly improve the response time of the application.

• This software architecture pattern can provide an audit log out of the box. Each event represents a manipulation of the data at a certain point in time.
• It requires some discipline because you can’t just fix wrong data with a simple edit in the database.
• It’s not a trivial task to change the structure of an event. For example, if you add a property, the database still contains events without that data. Your code will need to handle this missing data graciously.

Ideal for Applications That:

•  Need to publish events to external systems
• Will be built with CQRS
• Have complex domains
• Need an audit log of changes to the data

5. The Microservices Architectural Pattern

When you write your application as a set of microservices, you’re actually writing multiple applications that will work together. Each microservice has its own distinct responsibility and teams can develop them independently of other microservices.

The only dependency between them is the communication. As microservices communicate with each other, you will have to make sure messages sent between them remain backwards compatible. This requires some coordination, especially when different teams are responsible for different microservices.

A diagram can explain.

You can imagine this is an application where the user can order something. The separate microservices can call each other too. For example, the payment service may notify the orders service when a payment succeeds. The orders service could then call the inventory service to adjust the stock.

There is no clear rule of how big a microservice can be. In the previous example, the user profile service may be responsible for data like the username and password of a user, but also the home address, avatar image, favorites, etc. It could also be an option to split all those responsibilities into even smaller microservices.

• You can write, maintain, and deploy each microservice separately.
• A microservices architecture should be easier to scale, as you can scale only the microservices that need to be scaled. There’s no need to scale the less frequently used pieces of the application.
• It’s easier to rewrite pieces of the application because they’re smaller and less coupled to other parts.
• Contrary to what you might expect, it’s actually easier to write a well-structured monolith at first and split it up into microservices later. With microservices, a lot of extra concerns come into play: communication, coordination, backward compatibility, logging, etc. Teams that miss the necessary skill to write a well-structured monolith will probably have a hard time writing a good set of microservices.
• A single action of a user can pass through multiple microservices. There are more points of failure, and when something does go wrong, it can take more time to pinpoint the problem.
• Applications where certain parts will be used intensively and need to be scaled
• Services that provide functionality to several other applications
• Applications that would become very complex if combined into one monolith
• Applications where clear bounded contexts can be defined

I’ve explained several software architecture patterns, as well as their advantages and disadvantages. But there are more patterns than the ones I’ve laid out here. It is also not uncommon to combine several of these patterns.

They aren’t always mutually exclusive. For example, you could have several microservices and have some of them use the layered pattern, while others use CQRS and event sourcing.

The important thing to remember is that there isn’t one solution that works everywhere. When we ask the question of which pattern to use for an application, the age-old answer still applies: “it depends.”

You should weigh in on the pros and cons of a solution and make a well-informed decision.

Make your .NET code beautiful with NDepend

Download the NDepend Trial and gain valuable insights into your .NET code within a few minutes

• Pingback: Software Architecture: the 5 Patterns You Need to Know – NDepend – Bitbucket Bits

Nice article, Peter! These are great essentials that every developer should know about.

I like the clear structure of the article. What I’m missing is a suggestion on the architecture of the services of a microservice architecture.

could be added in this list the architecture of ports and adapters, the clean architecture or the onion

Simply fantastic with real-time examples

Comments are closed.

Three-tier architecture is a well-established software application architecture that organizes applications into three logical and physical computing tiers: the presentation tier, or user interface; the application tier, where data is processed; and the data tier, where application data is stored and managed.

The chief benefit of three-tier architecture is that because each tier runs on its own infrastructure, each tier can be developed simultaneously by a separate development team. And can be updated or scaled as needed without impacting the other tiers.

For decades three-tier architecture was the prevailing architecture for client-server applications. Today, most three-tier applications are targets for modernization that uses cloud-native technologies such as containers and microservices and for migration to the cloud.

Connect and integrate your systems to prepare your infrastructure for AI.

Register for the guide on app modernization

Presentation tier

The presentation tier is the user interface and communication layer of the application, where the end user interacts with the application. Its main purpose is to display information to and collect information from the user. This top-level tier can run on a web browser, as desktop application, or a graphical user interface (GUI), for example. Web presentation tiers are developed by using HTML, CSS, and JavaScript. Desktop applications can be written in various languages depending on the platform.

Application tier

The application tier, also known as the logic tier or middle tier, is the heart of the application. In this tier, information that is collected in the presentation tier is processed - sometimes against other information in the data tier - using business logic, a specific set of business rules. The application tier can also add, delete, or modify data in the data tier. 

The application tier is typically developed by using Python, Java, Perl, PHP or Ruby, and communicates with the data tier by using  API  calls. 

The data tier, sometimes called database tier, data access tier or back-end, is where the information that is processed by the application is stored and managed. This can be a  relational database management system  such as  PostgreSQL , MySQL, MariaDB, Oracle, Db2, Informix or Microsoft SQL Server, or in a  NoSQL  Database server such as Cassandra,  CouchDB , or  MongoDB . 

In a three-tier application, all communication goes through the application tier. The presentation tier and the data tier cannot communicate directly with one another.

Tier versus layer

In discussions of three-tier architecture,  layer  is often used interchangeably – and mistakenly – for  tier , as in 'presentation layer' or 'business logic layer'. 

They aren't the same. A 'layer' refers to a functional division of the software, but a 'tier' refers to a functional division of the software that runs on infrastructure separate from the other divisions. The Contacts app on your phone, for example, is a  three - layer  application, but a  single-tier  application, because all three layers run on your phone.

The difference is important because layers can't offer the same benefits as tiers.

Again, the chief benefit of three-tier architecture is its logical and physical separation of functionality. Each tier can run on a separate operating system and server platform - for example, web server, application server, database server - that best fits its functional requirements. And each tier runs on at least one dedicated server hardware or virtual server, so the services of each tier can be customized and optimized without impacting the other tiers. 

Other benefits (compared to single- or two-tier architecture) include:

• Faster development : Because each tier can be developed simultaneously by different teams, an organization can bring the application to market faster. And programmers can use the latest and best languages and tools for each tier.
• Improved scalability : Any tier can be scaled independently of the others as needed.
• Improved reliability : An outage in one tier is less likely to impact the availability or performance of the other tiers.
• Improved security : Because the presentation tier and data tier can't communicate directly, a well-designed application tier can function as an internal firewall, preventing SQL injections and other malicious exploits.

In web development, the tiers have different names but perform similar functions:

• The web server  is the presentation tier and provides the user interface. This is usually a web page or website, such as an ecommerce site where the user adds products to the shopping cart, adds payment details or creates an account. The content can be static or dynamic, and is developed using HTML, CSS, and JavaScript.
• The application server  corresponds to the middle tier, housing the business logic that is used to process user inputs. To continue the ecommerce example, this is the tier that queries the inventory database to return product availability, or adds details to a customer's profile. This layer often developed using Python, Ruby, or PHP and runs a framework such as Django, Rails, Symphony, or ASP.NET.
• The database server  is the data or backend tier of a web application. It runs on database management software, such as MySQL, Oracle, DB2, or PostgreSQL.

While three-tier architecture is easily the most widely adopted multitier application architecture, there are others that you might encounter in your work or your research.

Two-tier architecture 

Two-tier architecture is the original client-server architecture, consisting of a presentation tier and a data tier; the business logic lives in the presentation tier, the data tier or both. In two-tier architecture the presentation tier - and therefore the end user - has direct access to the data tier, and the business logic is often limited. A simple contact management application, where users can enter and retrieve contact data, is an example of a two-tier application. 

N-tier architecture

N-tier architecture - also called or multitier architecture - refers to  any  application architecture with more than one tier. But applications with more than three layers are rare because extra layers offer few benefits and can make the application slower, harder to manage and more expensive to run. As a result, n-tier architecture and multitier architecture are usually synonyms for three-tier architecture.

Move to cloud faster with IBM Cloud Pak solutions running on Red Hat OpenShift software—integrated, open, containerized solutions certified by IBM®.

Seamlessly modernize your VMware workloads and applications with IBM Cloud.

Modernize, build new apps, reduce costs, and maximize ROI.

IBM Consulting® application modernization services, which are powered by IBM Consulting Cloud Accelerator, offers skills, methods, tools, and initiatives that help determine the right strategy based on your portfolio. To modernize and containerize legacy system applications and accelerate the time-to-value of hybrid cloud environments. 

Discover what application modernization is, the common benefits and challenges, and how to get started.

Learn about how relational databases work and how they compare to other data storage options.

Explore cloud native applications and how they drive innovation and speed within your enterprise.

Modernize your legacy three-tier applications on your journey to cloud. Whether you need assistance with strategy, processes, or capabilities—or want full-service attention—IBM can help. Start using containerized middleware that can run in any cloud—all bundled in IBM Cloud Paks.

3 Layered Architecture

Introduction.

Here in this article, I would like to cover the typical three layer architecture in C# .NET. It is a very useful approach for coding due to easy code maintenance.

First let me give you a small overview about the topic I would like to cover in this article.

• Tier vs. Layer
• Three Tier/Layer Architecture Design Components
• Demo: Three Layer Windows Application in C#.NET

1. Tier vs. Layer

1.1 Tier: Tier indicates a physical separation of components, which may mean different assemblies such as DLL, EXE, etc. on the same server or multiple servers.

As you can see in the above figure, Data Tier have no direction with Presentation Tier, but there is an intermediate Tier called Business Tier which is mainly responsible to pass the data from Data Tier to Presentation Tier and to add defined business logic to Data.

So, if we separate each Tier by its functionality, then we come to know the below conclusion:

1.2 Layer: Layer indicates logical separation of components, such as having distinct namespaces and classes for the Database Access Layer, Business Logic Layer and User Interface Layer.

2. Three Tier/Layer Architecture Design Components

As we have already seen, tier is the sum of all the physical components. We can separate the three tiers as Data Tier, Business Tier and Presentation Tier.

• Data Tier is basically the server which stores all the application’s data. Data tier contents Database Tables, XML Files and other means of storing Application Data.
• Business Tier is mainly working as the bridge between Data Tier and Presentation Tier. All the Data passes through the Business Tier before passing to the presentation Tier. Business Tier is the sum of Business Logic Layer, Data Access Layer and Value Object and other components used to add business logic.
• Presentation Tier is the tier in which the users interact with an application. Presentation Tier contents Shared UI code, Code Behind and Designers used to represent information to user.

The above figure is a mixture of Three Tier and Three Layer Architecture. Here, we can clearly see a different between Tier and Layer. Since each component is independent of each other, they are easily maintainable without changing the whole code.

This approach is really very important when several developers are working on the same project and some module needs to be re-used in another project. In a way, we can distribute work among developers and also maintain it in the future without much problems.

Testing is also a very important issue for Architecture when we are considering writing a test case for the project. Since it’s like a modular architecture, it’s very handy testing each module and to trace out bugs without going through the entire code.

3 . Demo: 3 Layer Windows Application in C#.NET

Let’s go though from one module to other to have a better understanding of it.

dbConnection

This class is mainly used to do the database activity like Select, Update and Delete query to database. It also checks if the database connection is open or not. If database connection is not open, then it opens the connection and performs the database query. The database results are to be received and being passing in Data Table in this class.

This class takes the database setting from the app.config file so it’s really flexible to manage the database settings.

Database Access Layer

Database Access Layer (DAO) builds the query based on received parameters from the Business Logic Layer and passes it the   dbConnection   class for execution. And simple return results from the   dbConnection   class to Business Logic Layer.

Value Object

Value Object is nothing more but a class with the contents   GET   and   SET   methods. It’s mainly used to pass Data from one class to another. It’s directly connected with Business Logic Layer and Presentation Layer. As you can see in the diagram object values are being SET in Business Logic Layer and GET from Presentation Layer.

Business Logic Layer

Business Logic Layer (BUS) works as a bridge between Presentation Layer and DAO. All the user values received from the presentation layer are being passed to BUS. The results received from the DAO are in row data in Data Table format but in BUS it’s converting into Value Objects (VO). Business Logic Layer (BUS) is the most important class in the whole architecture because it mainly contains all the business logic of the program. Whenever a user wants to update the business logic of the program only need to update this class.

Presentation Layer

Presentation Layer is the only layer which is directly connected with the user. So in this matter, it’s also a really important layer for marketing purposes. Presentation Layer is mainly used for getting user data and then passing it to Business Logic Layer for further procedure, and when data is received in Value Object then it’s responsible to represent value object in the appropriate form which user can understand.

Hope this artilce helps beginners in understanding the three layered architecture.

Leave a reply cancel reply.

Your email address will not be published. Required fields are marked *

Save my name, email, and website in this browser for the next time I comment.

With Canarys, Let’s Plan. Grow. Strive. Succeed.

Copyright © 2024 Canarys Automations Limited . All Rights Reserved.

• Stack Overflow for Teams Where developers & technologists share private knowledge with coworkers
• Advertising & Talent Reach devs & technologists worldwide about your product, service or employer brand
• OverflowAI GenAI features for Teams
• OverflowAPI Train & fine-tune LLMs
• Labs The future of collective knowledge sharing
• About the company Visit the blog

Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Get early access and see previews of new features.

Separation of Presentation layer from Business layer

From an article i just read,

UI Layer Abstraction

Well are there any setbacks to a full separation between the presentation layer and the business layer?

This question actually came from a problem of tracing the progress of a process (certain series of instructions) and updating a progress bar accordingly for example.

Now the only one who knows the actual progress is the process itself, and that is in the business layer. So if both layers are pretty separate, how can I reach the progress bar from within the business layer without stepping on the presentation layer's domain? Or at least return progress values to the presentation layer?

• architecture

7 Answers 7

IMHO the dialog about seperating layers misses one key fact: While layers need to be seperated for many reasons, that doesn't mean they can't do things to make things eaiser for the other layers.

We had a similar requirement - a progress bar for a long-running business process. What we did was define progress-events in the business layer code. These events would be called at vairous times - percentages complete, for example - and 'someone' subscribed to them. In our case, it was the UI layer!

So the layers are seperated, but 'business' has to understand that someone might want to watch it!

• yep that's what i'll do. Thanks a lot and thanks for all of you –  vassili zaietzef Commented Jul 8, 2009 at 15:13

dependency injection.

IOW your presentation layer implements some business layer callback interface (hence dependencies are in the good direction: ui->biz) and registers to the business component at runtime. In that case the business component sends progress updates to its callback interface and does not care of "who" is listening.

Obviously the buisness layer must know what progress has been made. It must then either tell the presentation layer when progress has been made or the presentation layer must ask the business layer. Whichever you prefer.

The key point is that the presentation layer should not be making a judgement of what progress has been made and the buisness layer must not be deciding how to present the information to the user.

• Thanks for putting it in uncomplicated terms! :-) –  oliver_siegel Commented May 21, 2014 at 13:56

Make the presentation layer query the business layer for progress status.

You should consider the "progress bar" as two separate pieces of logic as well.

The bar that the user sees is 100% presentation, and as such all logic to make it grow should be contained in the view.

Your business layer could they expose an "ProgressUpdated" event which simply fires every X percent.

The view would subscribe to said event, and display meaningfully on the UI.

An "inner" layer is able to call code in an "outer" layer, as long as the outer layer specifies what the callback code is. This can be expressed through objects, interface, delegates or function pointers, depending on the language.

Another one I've found is that the metadata of the business layer - e.g. field lengths and uniqueness in a database - are stuff that presentation layers need to know about.

You can either export it from the business layer or have it in a common module that the two share, but it's important you don't end up duplicating the same information in the business layer as database field lengths and in the presentation layer as input constraints.

Your Answer

Reminder: Answers generated by artificial intelligence tools are not allowed on Stack Overflow. Learn more

Sign up or log in

Post as a guest.

Required, but never shown

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy .

• The Overflow Blog
• Where developers feel AI coding tools are working—and where they’re missing...
• He sold his first company for billions. Now he’s building a better developer...
• Featured on Meta
• User activation: Learnings and opportunities
• Preventing unauthorized automated access to the network
• Should low-scoring meta questions no longer be hidden on the Meta.SO home...
• Announcing the new Staging Ground Reviewer Stats Widget

Hot Network Questions

• Do "always prepared" Spells cost spell slots?
• Were Soviet doctors and nurses actually as callous as "Voices from Chernobyl" portrays in the prolog?
• How to Vertically Stack Multiple Plots with Custom Color Functions and Opacity in Mathematica?
• Day Convolution of Sheaves
• What should you list as location in job application?
• Why did the Apollo 13 tank #2 have a heater and a vacuum?
• Is p→p a theorem in intuitionistic logic?
• What made scientists think that chemistry is reducible to physics and when did that happen?
• Navigating My Farewell: Insights for Managing My Exit
• Does legislation on transgender healthcare affect medical researchers?
• What causes, and how to avoid, finger numbness?
• CH in non-set theoretic foundations
• How to push 10-ft long 4" PVC pipe into 90-deg Elbow Hub?
• I want to find a smooth section of the map from the Stiefel manifold to the Grassmanian manifold
• How was the year spoken in late 1800s England?
• Why would an escrow/title company not accept ACH payments?
• Complexity of computing minimum unsatisfiable core
• Is “No Time To Die” the first Bond film to feature children?
• Rogue's Uncanny Dodge (reaction) versus Evasion on Dex saving throw
• What is an ellipse in infinite-dimensional spaces?
• Did Gauss really call Archimedes an idiot?
• How to apply a function to specific rows of a matrix
• Cost of Laos visa

This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

Creating a Business Logic Layer (C#)

• 9 contributors

by Scott Mitchell

Download PDF

In this tutorial we'll see how to centralize your business rules into a Business Logic Layer (BLL) that serves as an intermediary for data exchange between the presentation layer and the DAL.

Introduction

The Data Access Layer (DAL) created in the first tutorial cleanly separates the data access logic from the presentation logic. However, while the DAL cleanly separates the data access details from the presentation layer, it does not enforce any business rules that may apply. For example, for our application we may want to disallow the CategoryID or SupplierID fields of the Products table to be modified when the Discontinued field is set to 1, or we might want to enforce seniority rules, prohibiting situations in which an employee is managed by someone who was hired after them. Another common scenario is authorization perhaps only users in a particular role can delete products or can change the UnitPrice value.

In this tutorial we'll see how to centralize these business rules into a Business Logic Layer (BLL) that serves as an intermediary for data exchange between the presentation layer and the DAL. In a real-world application, the BLL should be implemented as a separate Class Library project; however, for these tutorials we'll implement the BLL as a series of classes in our App_Code folder in order to simplify the project structure. Figure 1 illustrates the architectural relationships among the presentation layer, BLL, and DAL.

Figure 1 : The BLL Separates the Presentation Layer from the Data Access Layer and Imposes Business Rules

Step 1: Creating the BLL Classes

Our BLL will be composed of four classes, one for each TableAdapter in the DAL; each of these BLL classes will have methods for retrieving, inserting, updating, and deleting from the respective TableAdapter in the DAL, applying the appropriate business rules.

To more cleanly separate the DAL- and BLL-related classes, let's create two subfolders in the App_Code folder, DAL and BLL . Simply right-click on the App_Code folder in the Solution Explorer and choose New Folder. After creating these two folders, move the Typed DataSet created in the first tutorial into the DAL subfolder.

Next, create the four BLL class files in the BLL subfolder. To accomplish this, right-click on the BLL subfolder, choose Add a New Item, and choose the Class template. Name the four classes ProductsBLL , CategoriesBLL , SuppliersBLL , and EmployeesBLL .

Figure 2 : Add Four New Classes to the App_Code Folder

Next, let's add methods to each of the classes to simply wrap the methods defined for the TableAdapters from the first tutorial. For now, these methods will just call directly into the DAL; we'll return later to add any needed business logic.

If you are using Visual Studio Standard Edition or above (that is, you're not using Visual Web Developer), you can optionally design your classes visually using the Class Designer . Refer to the Class Designer Blog for more information on this new feature in Visual Studio.

For the ProductsBLL class we need to add a total of seven methods:

• GetProducts() returns all products
• GetProductByProductID(productID) returns the product with the specified product ID
• GetProductsByCategoryID(categoryID) returns all products from the specified category
• GetProductsBySupplier(supplierID) returns all products from the specified supplier
• AddProduct(productName, supplierID, categoryID, quantityPerUnit, unitPrice, unitsInStock, unitsOnOrder, reorderLevel, discontinued) inserts a new product into the database using the values passed-in; returns the ProductID value of the newly inserted record
• UpdateProduct(productName, supplierID, categoryID, quantityPerUnit, unitPrice, unitsInStock, unitsOnOrder, reorderLevel, discontinued, productID) updates an existing product in the database using the passed-in values; returns true if precisely one row was updated, false otherwise
• DeleteProduct(productID) deletes the specified product from the database

ProductsBLL.cs

The methods that simply return data GetProducts , GetProductByProductID , GetProductsByCategoryID , and GetProductBySuppliersID are fairly straightforward as they simply call down into the DAL. While in some scenarios there may be business rules that need to be implemented at this level (such as authorization rules based on the currently logged on user or the role to which the user belongs), we'll simply leave these methods as-is. For these methods, then, the BLL serves merely as a proxy through which the presentation layer accesses the underlying data from the Data Access Layer.

The AddProduct and UpdateProduct methods both take in as parameters the values for the various product fields and add a new product or update an existing one, respectively. Since many of the Product table's columns can accept NULL values ( CategoryID , SupplierID , and UnitPrice , to name a few), those input parameters for AddProduct and UpdateProduct that map to such columns use nullable types . Nullable types are new to .NET 2.0 and provide a technique for indicating whether a value type should, instead, be null . In C# you can flag a value type as a nullable type by adding ? after the type (like int? x; ). Refer to the Nullable Types section in the C# Programming Guide for more information.

All three methods return a Boolean value indicating whether a row was inserted, updated, or deleted since the operation may not result in an affected row. For example, if the page developer calls DeleteProduct passing in a ProductID for a non-existent product, the DELETE statement issued to the database will have no affect and therefore the DeleteProduct method will return false .

Note that when adding a new product or updating an existing one we take in the new or modified product's field values as a list of scalars as opposed to accepting a ProductsRow instance. This approach was chosen because the ProductsRow class derives from the ADO.NET DataRow class, which doesn't have a default parameterless constructor. In order to create a new ProductsRow instance, we must first create a ProductsDataTable instance and then invoke its NewProductRow() method (which we do in AddProduct ). This shortcoming rears its head when we turn to inserting and updating products using the ObjectDataSource. In short, the ObjectDataSource will try to create an instance of the input parameters. If the BLL method expects a ProductsRow instance, the ObjectDataSource will try to create one, but fail due to the lack of a default parameterless constructor. For more information on this problem, refer to the following two ASP.NET Forums posts: Updating ObjectDataSources with Strongly-Typed DataSets , and Problem With ObjectDataSource and Strongly-Typed DataSet .

Next, in both AddProduct and UpdateProduct , the code creates a ProductsRow instance and populates it with the values just passed in. When assigning values to DataColumns of a DataRow various field-level validation checks can occur. Therefore, manually putting the passed in values back into a DataRow helps ensure the validity of the data being passed to the BLL method. Unfortunately the strongly-typed DataRow classes generated by Visual Studio do not use nullable types. Rather, to indicate that a particular DataColumn in a DataRow should correspond to a NULL database value we must use the SetColumnNameNull() method.

In UpdateProduct we first load in the product to update using GetProductByProductID(productID) . While this may seem like an unnecessary trip to the database, this extra trip will prove worthwhile in future tutorials that explore optimistic concurrency. Optimistic concurrency is a technique to ensure that two users who are simultaneously working on the same data don't accidentally overwrite one another's changes. Grabbing the entire record also makes it easier to create update methods in the BLL that only modify a subset of the DataRow's columns. When we explore the SuppliersBLL class we'll see such an example.

Finally, note that the ProductsBLL class has the DataObject attribute applied to it (the [System.ComponentModel.DataObject] syntax right before the class statement near the top of the file) and the methods have DataObjectMethodAttribute attributes . The DataObject attribute marks the class as being an object suitable for binding to an ObjectDataSource control , whereas the DataObjectMethodAttribute indicates the purpose of the method. As we'll see in future tutorials, ASP.NET 2.0's ObjectDataSource makes it easy to declaratively access data from a class. To help filter the list of possible classes to bind to in the ObjectDataSource's wizard, by default only those classes marked as DataObjects are shown in the wizard's drop-down list. The ProductsBLL class will work just as well without these attributes, but adding them makes it easier to work with in the ObjectDataSource's wizard.

Adding the Other Classes

With the ProductsBLL class complete, we still need to add the classes for working with categories, suppliers, and employees. Take a moment to create the following classes and methods using the concepts from the example above:

CategoriesBLL.cs

• GetCategories()
• GetCategoryByCategoryID(categoryID)

SuppliersBLL.cs

• GetSuppliers()
• GetSupplierBySupplierID(supplierID)
• GetSuppliersByCountry(country)
• UpdateSupplierAddress(supplierID, address, city, country)

EmployeesBLL.cs

• GetEmployees()
• GetEmployeeByEmployeeID(employeeID)
• GetEmployeesByManager(managerID)

The one method worth noting is the SuppliersBLL class's UpdateSupplierAddress method. This method provides an interface for updating just the supplier's address information. Internally, this method reads in the SupplierDataRow object for the specified supplierID (using GetSupplierBySupplierID ), sets its address-related properties, and then calls down into the SupplierDataTable 's Update method. The UpdateSupplierAddress method follows:

Refer to this article's download for my complete implementation of the BLL classes.

Step 2: Accessing the Typed DataSets Through the BLL Classes

In the first tutorial we saw examples of working directly with the Typed DataSet programmatically, but with the addition of our BLL classes, the presentation tier should work against the BLL instead. In the AllProducts.aspx example from the first tutorial, the ProductsTableAdapter was used to bind the list of products to a GridView, as shown in the following code:

To use the new BLL classes, all that needs to be changed is the first line of code simply replace the ProductsTableAdapter object with a ProductBLL object:

The BLL classes can also be accessed declaratively (as can the Typed DataSet) by using the ObjectDataSource. We'll be discussing the ObjectDataSource in greater detail in the following tutorials.

Figure 3 : The List of Products is Displayed in a GridView ( Click to view full-size image )

Step 3: Adding Field-Level Validation to the DataRow Classes

Field-level validation are checks that pertains to the property values of the business objects when inserting or updating. Some field-level validation rules for products include:

• The ProductName field must be 40 characters or less in length
• The QuantityPerUnit field must be 20 characters or less in length
• The ProductID , ProductName , and Discontinued fields are required, but all other fields are optional
• The UnitPrice , UnitsInStock , UnitsOnOrder , and ReorderLevel fields must be greater than or equal to zero

These rules can and should be expressed at the database level. The character limit on the ProductName and QuantityPerUnit fields are captured by the data types of those columns in the Products table ( nvarchar(40) and nvarchar(20) , respectively). Whether fields are required and optional are expressed by if the database table column allows NULL s. Four check constraints exist that ensure that only values greater than or equal to zero can make it into the UnitPrice , UnitsInStock , UnitsOnOrder , or ReorderLevel columns.

In addition to enforcing these rules at the database they should also be enforced at the DataSet level. In fact, the field length and whether a value is required or optional are already captured for each DataTable's set of DataColumns. To see the existing field-level validation automatically provided, go to the DataSet Designer, select a field from one of the DataTables and then go to the Properties window. As Figure 4 shows, the QuantityPerUnit DataColumn in the ProductsDataTable has a maximum length of 20 characters and does allow NULL values. If we attempt to set the ProductsDataRow 's QuantityPerUnit property to a string value longer than 20 characters an ArgumentException will be thrown.

Figure 4 : The DataColumn Provides Basic Field-Level Validation ( Click to view full-size image )

Unfortunately, we can't specify bounds checks, such as the UnitPrice value must be greater than or equal to zero, through the Properties window. In order to provide this type of field-level validation we need to create an event handler for the DataTable's ColumnChanging event. As mentioned in the preceding tutorial , the DataSet, DataTables, and DataRow objects created by the Typed DataSet can be extended through the use of partial classes. Using this technique we can create a ColumnChanging event handler for the ProductsDataTable class. Start by creating a class in the App_Code folder named ProductsDataTable.ColumnChanging.cs .

Figure 5 : Add a New Class to the App_Code Folder ( Click to view full-size image )

Next, create an event handler for the ColumnChanging event that ensures that the UnitPrice , UnitsInStock , UnitsOnOrder , and ReorderLevel column values (if not NULL ) are greater than or equal to zero. If any such column is out of range, throw an ArgumentException .

ProductsDataTable.ColumnChanging.cs

Step 4: Adding Custom Business Rules to the BLL's Classes

In addition to field-level validation, there may be high-level custom business rules that involve different entities or concepts not expressible at the single column level, such as:

• If a product is discontinued, its UnitPrice cannot be updated
• An employee's country of residence must be the same as their manager's country of residence
• A product cannot be discontinued if it is the only product provided by the supplier

The BLL classes should contain checks to ensure adherence to the application's business rules. These checks can be added directly to the methods to which they apply.

Imagine that our business rules dictate that a product could not be marked discontinued if it was the only product from a given supplier. That is, if product X was the only product we purchased from supplier Y , we could not mark X as discontinued; if, however, supplier Y supplied us with three products, A , B , and C , then we could mark any and all of these as discontinued. An odd business rule, but business rules and common sense aren't always aligned!

To enforce this business rule in the UpdateProducts method we'd start by checking if Discontinued was set to true and, if so, we'd call GetProductsBySupplierID to determine how many products we purchased from this product's supplier. If only one product is purchased from this supplier, we throw an ApplicationException .

Responding to Validation Errors in the Presentation Tier

When calling the BLL from the presentation tier we can decide whether to attempt to handle any exceptions that might be raised or let them bubble up to ASP.NET (which will raise the HttpApplication 's Error event). To handle an exception when working with the BLL programmatically, we can use a try...catch block, as the following example shows:

As we'll see in future tutorials, handling exceptions that bubble up from the BLL when using a data Web control for inserting, updating, or deleting data can be handled directly in an event handler as opposed to having to wrap code in try...catch blocks.

A well architected application is crafted into distinct layers, each of which encapsulates a particular role. In the first tutorial of this article series we created a Data Access Layer using Typed DataSets; in this tutorial we built a Business Logic Layer as a series of classes in our application's App_Code folder that call down into our DAL. The BLL implements the field-level and business-level logic for our application. In addition to creating a separate BLL, as we did in this tutorial, another option is to extend the TableAdapters' methods through the use of partial classes. However, using this technique does not allow us to override existing methods nor does it separate our DAL and our BLL as cleanly as the approach we've taken in this article.

With the DAL and BLL complete, we're ready to start on our presentation layer. In the next tutorial we'll take a brief detour from data access topics and define a consistent page layout for use throughout the tutorials.

Happy Programming!

About the Author

Scott Mitchell, author of seven ASP/ASP.NET books and founder of 4GuysFromRolla.com , has been working with Microsoft Web technologies since 1998. Scott works as an independent consultant, trainer, and writer. His latest book is Sams Teach Yourself ASP.NET 2.0 in 24 Hours . He can be reached at [email protected]. or via his blog, which can be found at http://ScottOnWriting.NET .

Special Thanks To

This tutorial series was reviewed by many helpful reviewers. Lead reviewers for this tutorial were Liz Shulok, Dennis Patterson, Carlos Santos, and Hilton Giesenow. Interested in reviewing my upcoming MSDN articles? If so, drop me a line at [email protected].

Previous Next

Was this page helpful?

Additional resources