In programming, the Business Logic Layer (BLL) serves as an intermediary for data exchange between the presentation layer and the Data Access Layer (DAL). The Business Logic Layer handles the business rules, calculations, and logic within an application which dictate how it behaves. That is, the BLL determines how data from the database is used and what it can and cannot do within the application itself.
Understanding a business logic layer
The business logic layer handles the business rules, calculations, and logic within an application which dictate how it behaves. That is, the BLL determines how data from the database is used and what it can and cannot do within the application itself.
In this way, the business logic layer manages communication between the database and the presentation layer – sometimes referred to as the end-user interface. It forms part of the multitier architecture of software engineering where various functions are physically separated.
Separation typically involves functions assigned to one of three layers:
- User interface (UI) layer – where all presentation and user interaction occurs. Data is displayed to the user. The user sends and also receives data.
- Business logic layer (BLL) – as we have noted, the BLL deals with application processing and coordinates the flow of data between the UI and DAL.
- Data access layer (DAL) – or the layer where data management takes place. In most cases, this is via a web service or database.
Collectively, each of the three layers plays an integral role in many web applications. Consider the example of an insurance website that features an application where consumers can view their insurance policies.
The consumer’s browser interacts with the application’s user interface layer code, with customer policy data held in the data access layer. The BLL is the most important component since it contains any important calculations or business logic and ultimately, determines whether the consumer is entitled to obtain insurance cover.
Business logic sets out how business objects interact with each other and enforces how these objects are updated and accessed. Logic decides how data is transformed, calculated, and sent to workflows, which are the ordered tasks one participant (user, software) sends to another.
Business rules, on the other hand, are formal expressions of “real-world” business policy, such as those relating to loans, accounts, and itineraries.
To explain the difference more succinctly, it can be helpful to remember that any procedure or process falls under the business logic banner. Any factor that is neither of these can be considered a business rule.
When a consumer visits an eCommerce website, for example, business logic defines a workflow where the consumer can add a product to their cart, enter their postal address, provide their credit card details, and land on a confirmation page. An example of a business rule in this process may describe a particular method for communicating with the VisaNet electronic payments network.
Defining a business logic layer
Both the UI and DAL are relatively easy to define and understand. However, there is less clarity on what constitutes a BLL. As a result, many businesses (including Apple and Microsoft) exclude the BLL from their applications entirely and have UI code communicate directly with the DAL.
In coding, this leads to what is colloquially called the “Fat Controller”. This describes a controller with domain logic servicing too many requests. In turn, controller logic becomes overly complex and too dependent on domain concepts. Ultimately, this complexity makes code maintenance difficult.
Generally speaking, this code is any which deals with the following:
- Persisting data (to the DAL).
- Displaying data (to the UI layer).
- Accessing data (from the DAL).
- Making logical decisions.
- Performing calculations.
- Maintaining application state.
- Coordinating workflow.
- Processing commands (from the UI layer).
Used properly, the BLL centralizes as much common logic as possible and is not tied to a particular UI. This enables the application to support any number of user interfaces and minimizes instances of code duplication.
It’s also worth noting that the code in the UI layer must necessarily shrink as it grows in the BLL. This concept is central to the “Thin Controller” theory. As the BLL grows and starts to become bloated, the layer can be separated further by moving from a three-tier to an n-tier architecture.
Benefits of business logic layers
Business logic layers are a recommended software engineering convention. Together with the user interface and data access layers, this multitier architecture has important implications for code reusability and modular design.
To that end, there are several benefits to adopting the compartmentalized approach:
- Code maintenance – as we touched on briefly in the previous section, multitier architecture makes code maintenance much easier. When a business requirement changes, the associated business logical layer is often the only component that requires code to be altered. By the same token, it can be very difficult to determine where in the application a code change should be made if there is no compartmentalization whatsoever.
- Application releases – another benefit of the business logic layer and multitiered architecture is the ease with which application releases can be rolled out. It stands to reason that if the BLL was the only layer to be updated, then it is the only one that should be used in the production environment. That is, the user interface layer and data access layer can be left alone and remain unaltered.
- Ease of learning – development teams may also benefit from the BLL and multitier architecture approach. Individual employees need only specialize in presentation development, data, or business logic skills to more rapidly learn their specific part of the application. This also has positive implications for efficiency. Since each layer can be worked on at the same time, the development timeframe becomes shorter.
- A business logic layer serves as an intermediary for data exchange between the data access layer (DAL) and the user interface (UI) layer.
- Finding it too difficult to define, many businesses omit the business logic layer completely. With the DAL communicating directly with the UI, code becomes overly complex and maintenance problematic.
- A business logic layer allows developers to design applications that support multiple user interfaces. This minimizes the chances of needless code duplication.
Connected Business Concepts
Main Free Guides: