Black and blue background

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 the data associated with the application 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 , using cloud-native technologies such as containers and microservices , and for migration to the cloud.

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 usually developed using HTML, CSS and JavaScript. Desktop applications can be written in a variety of 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 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 using Python, Java, Perl, PHP or Ruby, and communicates with the data tier using  API  calls. 

The data tier, sometimes called database tier, data access tier or back-end, is where the information 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 vs. 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 its logical and physical separation of functionality. Each tier can run on a separate operating system and server platform - e.g., 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 impact 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 a sort of 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 web site, 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 usually developed using HTML, CSS and Javascript.
  • The application server  corresponds to the middle tier, housing the business logic 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 e Django, Rails, Symphony or ASP.NET, for example.
  • 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, for example.

While three-tier architecture is easily the most widely-adopted multi-tier application architecture, there are others 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 consequently 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 multi-tier architecture - refers to  any  application architecture with more than one tier. But applications with more than three layers are rare, because additional 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 multi-tier 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, 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.

IBM Cloud® offers products and services to help you 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—explore how IBM can help with application modernization. Start using containerized middleware that can run in any cloud—all bundled in IBM Cloud Paks®.

Application Architecture Overview

Systems Analysis and Design Tutorial

An application system consists of three logical layers.

The presentation layer is what a system user sees or interacts with.  It can consist of visual objects such as screens, web pages or reports or non-visual objects such as an interactive voice response interface.

When most people think of application systems, they think mainly of the presentation layer.  Unfortunately, this layer represents a small portion of the effort involved in building application systems.

The business logic layer, on the other hand, implements and enforces the business rules via programming logic (computer instructions).

This business logic layer might on the surface appear to be very straight forward, however, that is rarely so.

Application Architecture Concepts

The data access layer consists of the definitions of database tables and columns and the computer logic that is needed to navigate the database.

The layer in the application architecture enforces rules regarding the storage and access of information. For example: All date fields must be valid dates.  All numeric fields must never contain alphanumeric characters.

This diagram on this page is a "logical" representation of an application system.  When a system is implemented, application system components can be physically deployed on different computer systems.

For example, the presentation of the web page you are looking at is being handled by your computer or mobile device.  The logic required to consolidate and communicate the visual objects that it needs is occurring on a web server located in Virginia USA.

Presentation Domain Data Layering

26 August 2015

Martin Fowler

team organization

encapsulation

application architecture

web development

One of the most common ways to modularize an information-rich program is to separate it into three broad layers: presentation (UI), domain logic (aka business logic), and data access. So you often see web applications divided into a web layer that knows about handling HTTP requests and rendering HTML, a business logic layer that contains validations and calculations, and a data access layer that sorts out how to manage persistent data in a database or remote services.

On the whole I've found this to be an effective form of modularization for many applications and one that I regularly use and encourage. It's biggest advantage (for me) is that it allows me to reduce the scope of my attention by allowing me to think about the three topics relatively independently. When I'm working on domain logic code I can mostly ignore the UI and treat any interaction with data sources as an abstract set of functions that give me the data I need and update it as I wish. When I'm working on the data access layer I focus on the details of wrangling the data into the form required by my interface. When I'm working on the presentation I can focus on the UI behavior, treating any data to display or update as magically appearing by function calls. By separating these elements I narrow the scope of my thinking in each piece, which makes it easier for me to follow what I need to do.

This narrowing of scope doesn't imply any sequence to programming them - I usually find I need to iterate between the layers. I might build the data and domain layers off my initial understanding of the UX, but when refining the UX I need to change the domain which necessitates a change to the data layer. But even with that kind of cross-layer iteration, I find it easier to focus on one layer at a time as I make changes. It's similar to the switching of thinking modes you get with refactoring's two hats .

Another reason to modularize is to allow me to substitute different implementations of modules. This separation allows me to build multiple presentations on top of the same domain logic without duplicating it. Multiple presentations could be separate pages in a web app, having a web app plus mobile native apps, an API for scripting purposes, or even an old fashioned command line interface. Modularizing the data source allows me to cope gracefully with a change in database technology, or to support services for persistence that may change with little notice. However I have to mention that while I often hear about data access substitution being a driver for separating the data source layer, I rarely hear of someone actually doing it.

Modularity also supports testability, which naturally appeals to me as a big fan of SelfTestingCode . Module boundaries expose seams that are good affordance for testing . UI code is often tricky to test, so it's good to get as much logic as you can into a domain layer which is easily tested without having to do gymnastics to access the program through a UI [1] . Data access is often slow and awkward, so using TestDoubles around the data layer often makes domain logic testing much easier and responsive.

While substitutability and testability are certainly benefits of this layering, I must stress that even without either of these reasons I would still divide into layers like this. The reduced scope of attention reason is sufficient on its own.

When talking about this we can either look at it as one pattern (presentation-domain-data) or split it into two patterns (presentation-domain, and domain-data). Both points of view are useful - I think of presentation-domain-data as a composite of presentation-domain and domain-data.

I consider these layers to be a form of module, which is a generic word I use for how we clump our software into relatively independent pieces. Exactly how this corresponds to code depends on the programming environment we're in. Usually the lowest level is some form of subroutine or function. An object-oriented language will have a notion of class that collects functions and data structure. Most languages have some form of higher level called packages or namespaces, which often can be formed into a hierarchy. Modules may correspond to separately deployable units: libraries, or services, but they don't have to.

Layering can occur at any of these levels. A small program may just put separate functions for the layers into different files. A larger system may have layers corresponding to namespaces with many classes in each.

I've mentioned three layers here, but it's common to see architectures with more than three layers. A common variation is to put a service layer between the domain and presentation, or to split the presentation layer into separate layers with something like Presentation Model . I don't find that more layers breaks the essential pattern, since the core separations still remain.

The dependencies generally run from top to bottom through the layer stack: presentation depends on the domain, which then depends on the data source. A common variation is to arrange things so that the domain does not depend on its data sources by introducing a mapper between the domain and data source layers. This approach is often referred to as a Hexagonal Architecture .

These layers are logical layers not physical tiers. I can run all three layers on my laptop, I can run the presentation and domain model in a desktop with a database on a server, I can split the presentation with a rich client in the browser and a Backed For Frontend on the server. In that case I treat the BFF as a presentation layer as it's focused on supporting a particular presentation option.

Although presentation-domain-data separation is a common approach, it should only be applied at a relatively small granularity. As an application grows, each layer can get sufficiently complex on its own that you need to modularize further. When this happens it's usually not best to use presentation-domain-data as the higher level of modules. Often frameworks encourage you to have something like view-model-data as the top level namespaces; that's OK for smaller systems, but once any of these layers gets too big you should split your top level into domain oriented modules which are internally layered.

Developers don't have to be full-stack but teams should be.

One common way I've seen this layering lead organizations astray is the AntiPattern of separating development teams by these layers. This looks appealing because front-end and back-end development require different frameworks (or even languages) making it easy for developers to specialize in one or the other. Putting those people with common skills together supports skill sharing and allows the organization to treat the team as a provider of a single, well-delineated type of work. In the same way, putting all the database specialists together fits in with the common centralization of databases and schemas. But the rich interplay between these layers necessitates frequent swapping between them. This isn't too hard when you have specialists in the same team who can casually collaborate, but team boundaries add considerable friction, as well as reducing an individual's motivation to develop the important cross-layer understanding of a system. Worse, separating the layers into teams adds distance between developers and users. Developers don't have to be full-stack (although that is laudable) but teams should be.

Further Reading

I've written about this separation from a number of different angles elsewhere. This layering drives the structure of P of EAA and chapter 1 of that book talks more about this layering. I didn't make this layering a pattern in its own right in that book but have toyed with that territory with Separated Presentation and PresentationDomainSeparation .

For more on why presentation-domain-data shouldn't be the highest level modules in a larger system, take a look at the writing and speaking of Simon Brown . I also agree with him that software architecture should be embedded in code.

I had a fascinating discussion with my colleague Badri Janakiraman about the nature of hexagonal architectures. The context was mostly around applications using Ruby on Rails, but much of the thinking applies to other cases when you may be considering this approach.

Acknowledgements

1: A PageObject is also an important tool to help testing around UIs.

presentation business data access layer

11 July 2006

517355 views

Printer friendly version

.NET Application Architecture: the Data Access Layer

Find out how to design a robust data access layer for your .NET applications.

Designing and building a robust data access layer

Building an understanding of architectural concepts is an essential aspect of managing your career. Technical interviews normally contain a battery of questions to gauge your architectural knowledge during the hiring process, and your architectural ability only becomes more important as you ascend through the ranks. So it’s always a good idea to make sure you have a good grasp on the fundamentals. In this article you will explore a key component of application architecture known as the Data Access Layer (DAL), which helps separate data-access logic from your business objects. The article discusses the concepts behind the DAL, and the associated PDF file takes a look at a full-blown DAL implementation. This is the first in a series of articles discussing some of the cool things you can do with a DAL, so the code and concepts in this article form the base for future discussions.

Layered design and the data access layer

Layered application designs are extremely popular because they increase application performance, scalability, flexibility, code reuse, and have a myriad of other benefits that I could rattle off if I had all of the architectural buzzwords memorized. In the classic three tier design, applications break down into three major areas of functionality:

  • The data layer manages the physical storage and retrieval of data
  • The business layer maintains business rules and logic
  • The presentation layer houses the user interface and related presentation code.

Inside each of these tiers there may also exist a series of sub-layers that provide an even more granular break up the functional areas of the application. Figure 1 outlines a basic three tired architecture in ASP.NET along with some of the sub-tiers that you may encounter:

253-DAL001.jpg

Figure 1 – Three tiered ASP.NET application with sub-tiers

The presentation tier

In the presentation layer, the code-behind mechanism for ASP.NET pages and user controls is a prominent example of a layered design. The markup file defines the look and layout of the web form and the code behind file contains the presentation logic. It’s a clean separation because both the markup and the code-behind layers house specific sets of functionality that benefit from being apart. Designers don’t have to worry about messing up code to make user interface changes, and developers don’t have to worry about sifting through the user-interface to update code.

The data tier

You also see sub-layers in the data tier with database systems. Tables define the physical storage of data in a database, but stored procedures and views allow you to manipulate data as it goes into and out of those tables. Say, for example, you need to denormalize a table and therefore have to change its physical storage structure. If you access tables directly in the business layer, then you are forced to update your business tier to account for the changes to the table. If you use a layer of stored procedures and views to access the data, then you can expose the same logical structure by updating a view or stored procedure to account for the physical change without having to touch any code in your business layer. When used appropriately, a layered design can lessen the overall impact of changes to the application.

The business tier

And of course, this brings us to the topic of business objects and the Data Access Layer (also known as the DAL), two sub-layers within the business tier. A business object is a component that encapsulates the data and business processing logic for a particular business entity. It is not, however, a persistent storage mechanism. Since business objects cannot store data indefinitely, the business tier relies on the data tier for long term data storage and retrieval. Thus, your business tier contains logic for retrieving persistent data from the data-tier and placing it into business objects and, conversely, logic that persists data from business objects into the data tier. This is called data access logic.

Some developers choose to put the data access logic for their business objects directly in the business objects themselves, tightly binding the two together. This may seem like a logical choice at first because from the business object perspective it seems to keep everything nicely packaged. You will begin noticing problems, however, if you ever need to support multiple databases, change databases, or even overhaul your current database significantly. Let’s say, for example, that your boss comes to you and says that you will be moving your application’s database from Oracle to SQL Server and that you have four months to do it. In the meantime, however, you have to continue supporting whatever business logic changes come up. Your only real option is to make a complete copy of the business object code so you can update the data access logic in it to support SQL Server. As business object changes arise, you have to make those changes to both the SQL Server code base and the Oracle code base. Not fun. Figure 2 depicts this scenario:

253-DAL002.jpg

Figure 2 – Business objects with embedded data access logic

A more flexible option involves removing the data access logic from the business objects and placing it all in a separate assembly known as the DAL. This gives you a clean separation between your business objects and the data access logic used to populate those business objects. Presented with the same challenge of making the switch from Oracle to SQL Server, you can just make a copy of the Oracle DAL and then convert it to work with SQL Server. As new business requirements come in, you no longer need to make changes in multiple locations because you only maintain a single set of business objects. And when you are done writing the SQL Server DAL, your application has two functional data access layers. In other words, your application has the means to support two databases. Figure 3 depicts separating data access logic out into a separate DAL:

253-DAL003.jpg

Figure 3 – Business objects with separate data access layer

Design principals in the data access layer

The objective of the DAL is to provide data to your business objects without using database specific code. You accomplish this by exposing a series of data access methods from the DAL that operate on data in the data-tier using database specific code but do not expose any database specific method parameters or return types to the business tier. Any time a business object needs to access the data tier, you use the method calls in the DAL instead of calling directly down to the data tier. This pushes database-specific code into the DAL and makes your business object database independent.

Now wait, you say, all you’ve accomplished is making the business objects dependent on the DAL. And since the DAL uses database-specific code, what’s the benefit? The benefit is that the DAL resides in its own assembly and exposes database-independent method signatures. You can easily create another DAL with the same assembly name and an identical set of method signatures that supports a different database. Since the method signatures are the same, your code can interface with either one, effectively giving you two interchangeable assemblies. And since the assembly is a physical file referenced by your application and the assembly names are the same, interchanging the two is simply a matter of placing one or the other into your application’s bin folder.

Note: You can also implement a DAL without placing it in a separate assembly if you build it against a DAL interface definition, but we will leave that to another article.

Exchanging Data with the DAL

Now the question is: how do you exchange data between your business objects, the DAL, and vice versa? All interaction between your business objects and the DAL occurs by calling data access methods in the DAL from code in your business objects. As mentioned previously, the method parameters and return values in the DAL are all database independent to ensure your business objects are not bound to a particular database. This means that you need to exchange data between the two using non-database-specific .NET types and classes. At first glance it may seem like a good idea to pass your business objects directly into the DAL so they can be populated, but it’s just not possible. The business object assembly references the DAL assembly, so the DAL assembly cannot reference the business object assembly or else you would get a circular reference error. As such, you cannot pass business objects down into the DAL because the DAL has no concept of your business objects. Figure 4 diagrams the situation:

253-DAL004.jpg

Figure 4 – Business objects assembly references the DAL, so the DAL has no concept of business objects

The custom class option

One option is to pass information in custom classes, as long as those custom classes are defined in an assembly that both the business object and DAL assemblies can reference. From an academic standpoint, this approach is probably the truest form of a data abstraction for a DAL because you can make the shared classes completely data-source independent and not just database independent. Figure 5 depicts how the business object assembly and the DAL assembly can both reference a shared assembly:

253-DAL005.jpg

Figure 5 – The business object assembly and the DAL assembly both reference a shared assembly, so they can exchange information using classes and data structures from the shared assembly.

In practice, I find that building out custom classes solely to exchange data doesn’t give you much return for your effort, especially when there are other acceptable options already built into .NET.

The XML approach

You could opt to use XML since it’s the poster child of flexibility and data-source independence and can easily represent any data imaginable. Of course, it also means that you will be doing a lot of XML parsing work to accommodate the data exchange, and I’m not a fan of extra work.

The database interface approach

You could also use the database interfaces from the System.Data namespace to exchange data between business objects and the DAL. Database specific objects such as SqlDataReader , SqlCommand , and SqlParameter are tied to SQL Server, and exposing them from the DAL would defeat the purpose. However, by exposing an IDataReader , IDBCommand , or IDataParameter object you do not tie yourself to particular database so they are an acceptable option, though not my first choice.

From an academic standpoint, the database interface objects do tie you to using a “database management system” even though they do not tie you to a specific database. Pure academics will tell you that the DAL should be “data-source independent” and not just “database independent” so be prepared for that fight if you have a Harvard or Oxford grad on your development team who majored in theoretical application design. Nobody else on the planet cares because the chances of your application moving away from a database system are fairly slim.

My preferred approach: DataSets

Another option for passing information, and the one that I gravitate towards because of its flexibility, is the DataSet. Microsoft created the DataSet class specifically for storing relational information in a non-database specific data structure, so the DataSet comes highly recommended for returning query information containing multiple records and or tables of data. Your work load shouldn’t suffer too significantly from using the DataSet because DataAdapters, which fill DataSets with information, already exists for most database systems. Furthermore, getting data out of the DataSet is fairly easy because it contains methods for extracting your data as tables, rows, and columns.

Also note that a DataSet is technically data-source independent, not just database independent. You can write custom code to load XML files, CSV files, or any other data source into a DataSet object. Additionally, you can even manipulate and move information around inside the DataSet, something that is not possible with the database interfaces from the System.Data namespace.

Exchanging non-relational data

Of course, you also deal with non-relational information when you pass data back and forth between your business objects and the DAL. For example, if you want to save a single business object to the data-tier, you have to pass that business object’s properties into the DAL. To do so, simply pass business object properties into the DAL via native .NET type method parameters. So a string property on your business object is passed into the DAL as a string parameter, and an int property on your business object is passed into the DAL as an int parameter. If the DAL updates the business object property, then you should mark the parameter with the ref modifier so the new value can be passed back to the business object. You can also use return values to return information as the result of a function when the need arises. Listing 1 contains examples of method signatures that you may need in the DAL if you have a Person business object in your application:

Listing 1 – Data access layer method signature examples

Data service classes

Normally you have one data access method in your DAL for each scenario in which you need to exchange data between a business object and the database. If, for example, you have a Person class then you may need data access methods like Person_GetAll , Person_GetPersonByID , Person_GetByLoginCredentials , Person_Update , Person_Delete , and so on, so you can do everything you need to do with a Person object via the DAL. Since the total number of data access methods in your DAL can get fairly large fairly quickly, it helps to separate those methods out into smaller more manageable Data Service Classes (or partial classes in .NET 2.0) inside your DAL. Aside from being more manageable from a shear number standpoint, breaking down the DAL into multiple data service classes helps reduce check-out bottle necks with your source control if you have multiple developers needing to work on the DAL at the same time. Figure 6 depicts a DAL broken down into three individual data service classes:

253-DAL006.jpg

Figure 6 – Breaking down the DAL into multiple data service classes

Notice that all of the data service classes depicted in Figure 3 derive from a single base class named DataServiceBase . The DataServiceBase class provides common data access functionality like opening a database connection, managing a transaction, setting up stored procedure parameters, executing commands, and so forth. In other words, the DataServiceBase class contains the general database code and provides you with a set of helper methods for use in the individual data service classes. The derived data service classes use the helper methods in the DataServiceBase for specific purposes, like executing a specific command or running a specific query.

Putting theory into practice: the demo application

At this point you should have a descent understanding of what the data access layer is and how it fits into an application from an architectural point of view. Theory is great, but at some point you have to quit talking and start coding. Of course, going from theory to practice is no trivial step, so I wanted to make sure you had a solid example to use as a foundation both in terms of code and understanding.

At the top of this article is a link to a zip file containing two items: a demo application containing a DAL implementation and a Building a Data Access Layer PDF that explains the code in detail. The application is fairly simple, a two page web app that allows you to view / delete a list of people on one page and to add / edit those people on another. However, it does implement all of the design principles that we’ve covered here. Enjoy!

Automate database deployments

Standardize team-based development - Prevent rework and conflicts, build consistency and quality into your code, and gain time for development that adds value, with standardized best practices for database development.

Find out more

Subscribe for more articles

Fortnightly newsletters help sharpen your skills and keep you ahead, with articles, ebooks and opinion to keep you informed.

Rate this article

presentation business data access layer

Damon Armstrong

Damon Armstrong is a consultant with SystemwarePS in Dallas, Texas. He is also a blogger and author of Pro ASP.NET 2.0 Website Programming and SharePoint 2013 Essentials for Developers . He specializes in the Microsoft stack with a focus on web technologies like MVC, ASP.NET, JavaScript, and SharePoint. When not staying up all night coding, he can be found watching a bunch of kids, studying Biblical topics, playing golf, or recovering from staying up all night coding.

Follow Damon Armstrong via

View all articles by Damon Armstrong

Load comments

Related articles

presentation business data access layer

Inline PDF Viewer in an Angular App? Now you can

presentation business data access layer

The Zen of Code Reviews: Review As If You Own the Code

Using c# to create powershell cmdlets: the basics.

Global Three Layer Application Architecture

Represent every system, subsystem, and application using a single and unified three layer architecture, regardless of its nature and role in the entire system or solution.

presentation business data access layer

Chaos of Different Architectures, Needlessly

I have seen many different software solutions, consisting of numerous different applications. With each application, I expect to see a single and unified architecture followed, but unfortunately that's not the case. Different applications often go their own ways by inventing yet another layering structure. Sometimes this simply means that layers have changed names, but mostly it means that I can't even relate the final architecture to the simple 3 layer application architecture.

This kind of diversity often results in:

  • Reinventing the wheel, since the existing 3 layers would solve the problem already;
  • Too many questions and communication overhead - when trying to understand or explain the system to others;
  • Confusion - because uncommon or unusual architectural decisions can be interpreted completely differently and not as envisioned by the author;
  • Bad quality - when a confused engineer tries to change or extend the system's behavior;
  • Maintenance headaches and many other outcomes of the bad quality and bad design.

Based on these findings, uncommon architectures should be avoided, unless absolutely necessary (which is almost never necessary).

There is definitely a need for the unified and common architectural layers, regardless of the kind of the application or system at hand.

The Three Layers

I don't need to go too far to look for the right answer. In most (if not all) cases, it's absolutely sufficient to follow the famous 3 layer software architecture. These layers are:

  • Presentation.
  • Business Logic.
  • Data Access.

Let's add couple of more guidelines to each of the layer.

Presentation layer is not just a user interface - it is an interaction point. Not just for the humans like you and me, but also for other applications that need to interact with the system at hand. e.g. for services, presentation layer is their service and operation contracts; for console applications it will be the console screen and functions to read from or write to the console. Whatever we expose to the outside world, that must be called Presentation. Some people associate this name with the user interface and so they would argue about the correctness for using this term here. But in my mind, it sounds absolutely fine, as it's something that we want to Present to the consumers of our application, be it a human or a machine. Presentation layer fulfills received requests and interactions by routing calls to the next layer - Business Logic. It could also invoke other systems or applications to fulfill the needs existing in the presentation layer itself. Interestingly, presentation layer of the current application interacts with other applications through their presentations layers - since it's the only layer for the consumer interaction.

Business Logic is usually a set of class libraries (or just classes and functions) containing domain models and other knowledge around the business, expressed in the current programming language. Other applications or systems don't directly interact with the business layer of the current application, since it's an implementation detail, standing behind the presentation layer (which is what is being exposed to others). Business logic layer in turn can interact with the next layer - Data Access. It could also invoke other systems or applications to fulfill the needs that exist within the business logic layer itself. Interaction with other applications or systems happens through their presentation layers only.

Data Access is where we persist data for the application or system. Other applications or systems don't directly interact with this layer. If they do want to do so, we have to expose such interaction points through the presentation layer. Data access layer sometimes will need to interact with other applications or systems to fulfill the data persistence related needs. This interaction should be happening by interacting with the presentation layer of the invoked applications or systems. e.g. we can connect to another service (through its presentation layer - service & operation contracts) to persist the data, instead of connecting to the database.

This may sound quite a lot to digest, but the guidelines are very simple and straightforward. Using those, we can construct an entire system of any complexity - either very simple or very complex. We will look at an example soon.

To summarize, these are the final guidelines we agreed on:

  • Exposes interaction capabilities for the end users or applications / systems wanting to interact with it.
  • Interacts with Business Logic layer.
  • Can interact with other applications (through their presentation layers).
  • Expresses domain knowledge, to be utilized from Presentation layer.
  • Interacts with Data Access layer.
  • Acts as a data persistence, to be utilized from Business Logic.

Example - System of Medium Complexity

Suppose we have a Single Page Application (SPA), consisting of UI, Web API, and Database. Web API calls into two different services for various purposes.

Below I will try to prove that every system represented in this example has the 3 layers in it.

presentation business data access layer

Many people mistakenly think of UI, Web API and Database as the layers of the application. While they do make sense to be the tiers (or even entirely separate applications), not all three of them could be considered as layers. e.g. Web API is not a layer, because inside Web API, we typically have layers of their own, such as HTTP request handlers and controllers (which I call Presentation), business logic, and data access. So, at least it's not hard to agree that the Web API does come with the 3 layers I'm talking about.

I also mentioned that the UI is an entirely separate application, and it really is - especially when we are dealing with SPAs. e.g. if we use MVC pattern (which is common due to Angular's popularity), then we express Views using HTML and CSS, we bind them to controllers containing JavaScript code, and we interact with Web API through Angular's services. These three comprise the regular 3 layers - Views being Presentation, Controllers being Business Logic, and Web API interaction through Angular's services being a Data Access layer. (For the architecture purists, Views and Controllers together could be considered as Presentation, while Business Logic and Data Access would both be different Angular services. That level of detail would cross the scope of simply explaining the existence of the three layers on the UI though. Don't quote me on the accuracy of the layer splitting in this article, since here I'm following a slightly different goal.)

For the sake of the example, our Web API is using two different services. Service #1 is used from Business Logic to fulfill some of the domain layer's needs, while Service #2 is used from Data Access layer to store specific kinds of data in it. (By the way, I recently wrote an article about distinguishing between Data Services and Business Services . So, in those terms, Service #1 would be a business service, while Service #2 would qualify as a data service.)

As we spoke before, both the services used from the Web API have similar layering structure, including service and operation contracts (that handle requests and responses), business logic and their own data access as well. Indeed, most of the services we invoke will already have all these layers, as they are considered to be a fully functional application that the clients can interact with.

For the sake of the argument, Database can also be split into layers, which I'll leave without further explanation, since I believe you have understood the point of this conversation.

Conclusion - everything comes in three layers .

Related Video: Universal Three Layer Application Architecture

While I was writing this article, I realized that I have written couple of others somewhat related to this topic. They don't quite repeat the subject, but they do support the thoughts expressed here. I guess that means my beliefs are as strong as before, and they don't fluctuate much. In other words, everything together makes sense .

Here are the related articles that I found:

Advanced JavaScript Application Architecture - speaks about layering UI applications, which I slightly touched here too.

Layering Software Architecture - speaks about the same layers, but more from implementation details, such as to avoid coupling between business logic and data access layers.

Data Services vs. Business Services - speaks about different kinds of services, which is related to my example above - using two different services - one from business logic and the other from the data access layer.

And finally, this is not an article but rather one more way to learn about software architecture - through my training courses that focus on architecture and development.

About Author and Content

The author of the above content is Tengiz Tutisani .

  • Check out Tengiz's book - Effective Software Development for Enterprise . If you liked the above content, you will like this book too, because it covers similar and relevant topics.
  • Consider our live, immersive technical workshop training courses around Software Architecture, Domain-Driven Design, and Extreme Programming topics, designed and delivered by Tengiz.
  • Review other services to see how we could work together!.

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.  

Alt Text

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. 

Alt Text

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.  

Alt Text

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.      

Alt Text

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.

Cover of Software Architecture Patterns

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.

presentation business data access layer

This browser is no longer supported.

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

Walkthrough: Creating the Data Access and Business Logic Layers in ASP.NET

When you work with data in ASP.NET, you will benefit by using common software patterns. One of these patterns is to separate the data-access code from the business-logic code that governs access to the data or that provides other business rules. In this pattern, these two layers are separate from the presentation layer, which consists of the pages that the Web site user accesses to view or change data.

A Visual Studio Web site project with source code is available to accompany this topic: Download .

ASP.NET can provide separation between data access, business logic, and presentation in several ways. For example, the data source model, which includes server controls such as the LinqDataSource and ObjectDataSource controls, separates the presentation layer from the data-access code and the business logic.

Another pattern is to include the data-access logic directly in the ASP.NET pages (the presentation layer). For example, you might write ADO.NET code in the ASP.NET page's code-behind page or use the SqlDataSource control. This approach tightly couples the data-access logic with the presentation layer.

The recommended approach is to separate the data access logic from the presentation layer. This separate layer is referred to as the data-access layer. The data-access layer can be implemented as a separate Class Library project. However, you can also use tools in Visual Web Developer that can generate a data-access layer for you.

If your Web site displays or updates data, you should create a data-access layer and business-logic layer before creating the user interface.

A data-driven Web application usually includes a data-access layer by using typed datasets or entity classes that represent the data. It also includes a business-logic layer that enforces custom business rules. Finally, it includes a presentation layer by using ASP.NET pages, and by using master pages and themes to create a common page layout. This walkthrough shows how to create a data-access layer.

The data-access layer includes all the code that is specific to the underlying data source. This includes code that creates a connection to the database and that issues Select, Insert, Update, and Delete commands. The data-access layer typically contains classes that implement methods for accessing the underlying database data. The presentation layer does not directly work with data. Instead, it invokes classes and methods in the data-access layer for all data requests. You can customize these classes using your own business logic.

Tasks illustrated in this walkthrough include the following:

Creating a SQL database and adding data.

Adding a LINQ to SQL file that acts as the data-access layer.

Creating a page that works as the presentation layer.

Adding a LinqDataSource control to a page that communicates between the presentation layer and the data-access layer.

Prerequisites

To complete the walkthrough, you will need the following:

Visual Studio or Visual Web Developer Express installed on your computer.

SQL Server Express. If you have Microsoft SQL Server installed, you can use that instead.

Creating A Web Site

The first step is to create a Web site.

This walkthrough uses a Web site project. You could use a Web application project instead. For information about the difference between these Web project types, see Web Application Projects versus Web Site Projects .

To create a new file system Web site

Open Visual Studio or Visual Web Developer Express.

In the File menu, click New Web Site .

The New Web Site dialog box is displayed.

Under Installed Templates , click Visual Basic or Visual C# and then select ASP.NET Web Site .

In the Web location box, select File System , and then enter the name of the folder where you want to keep the pages for your Web site.

For example, type the folder name C:\WebSites.

Visual Studio creates a Web site project that includes prebuilt functionality for layout (a master page, the Default.aspx and About.aspx content pages, and a cascading style sheet), for Ajax (client script files), and for authentication (ASP.NET membership).

Connecting to a Database

The next step is to connect to a database in Visual Web Developer by using the Server Explorer window. (In Visual Web Developer Express, the window is named Database Explorer .) Creating a connection to a database in Server Explorer lets you add tables, stored procedures, views, and other database elements, all within Visual Studio. You can also view table data or create queries manually or by using the Query Builder  window.

When you build the typed dataset for the data-access layer later in this walkthrough, you must create a connection in Visual Web Developer to the database. You can provide the connection information manually. However, Visual Web Developer can simplify this process because it automatically populates a list of the databases that are already registered in Server Explorer .

For this walkthrough you will create a new database for tracking task items.

Creating a New SQL Server Express Database

In this section you will create a new SQL Server Express database that will store task information for a to-do list.

To add a database to the Web site

In Solution Explorer , right-click the name of the Web site and then click Add New Item .

The Add New Item window is displayed.

Select SQL Database and name the database Tasks.mdf.

When Visual Web Developer asks you whether the database should be stored in the App_Data folder, click Yes .

Creating a Schema and Sample Data for the Tasks Database

You can use the database design and editing features to create a schema for the table that stores the task items.

To define a schema and add data for the Tasks database

In Solution Explorer , open the App_Data folder and double-click Tasks.mdf.

The Tasks database node is opened in Server Explorer .

Right-click the Tables folder and then click Add New Table .

The table definition window is displayed.

Create the following columns in the table:

Select the row for the taskId column, right-click the row, and then click Set Primary Key .

In the Properties window, set the Identity Column property to the taskId column.

Save the table, name it TasksList, and then close the table-definition window.

Right click the table in Server Explorer and then click Show Table Data .

An editing window is displayed where you can view, add, and edit the data.

Add four or five records to the table.

You do not have to specify a value for the taskId column, because it is an identity column and its value is automatically assigned.

Close the editing window.

Creating the Data Access and Business Logic Layers

You can create a data-access and business-logic layer for the database that you just created in several ways. You can customize these classes using your own business logic.

In this walkthrough, you will create a class that represents database entities. You can then add your own business logic to these generated classes. (You will not add business logic to the classes in this walkthrough.)

In this walkthrough, you will use Language Integrated Query (LINQ) to work with data. LINQ applies the principles of object-oriented programming to relational data. It provides a unified programming model for querying and updating data from different types of data sources and extends data capabilities directly into the C# and Visual Basic languages. For more information about LINQ, see LINQ (Language-Integrated Query) .

You will use LINQ to SQL classes as the data-access layer. You will use the Object Relational Designer window in Visual Web Developer to generate entity classes that represent the data.

Mapping the Tasks Database to a SQL Data Context Class

To begin creating the data-access layer, you add a typed dataset to the project.

To create a class for the Tasks table

If the Web site does not already have an App_Code folder, right-click the project in Solution Explorer , click Add ASP.NET Folder , and then click App_Code .

Right-click the App_Code folder and then click Add New Item .

The Add New Item dialog box is displayed.

Under Visual Studio installed templates , select the LINQ to SQL Classes template and rename the file Tasks.dbml.

Click Add .

The Object Relational Designer window is displayed.

In Server Explorer , drag the TasksList table into the Object Relational Designer window.

Save the Tasks.dbml file.

Visual Web Developer creates the Tasks.dbml.layout file in the App_Code folder under Tasks.dbml. It also creates either Tasks.designer.cs or Tasks.designer.vb, depending on what programming language you are working with.

In Solution Explorer , open the Tasks.designer.cs or Tasks.designer.vb file.

Notice that the code contains classes named TasksDataContext and TasksList. The TasksDataContext class represents the database, and the TasksList class represents the database table. The parameterless constructor for the TasksDataContext class reads the connection string for the database from the Web site's configuration file (Web.config).

Open the Web.config file.

Notice that a connection string to the Tasks database has been added in the connectionStrings element.

Close the class file and the Web.config file.

Creating and Configuring a LinqDataSource Control

Now that you have a database table and classes that represent database entities, you can use a LinqDataSource on an ASP.NET Web page to access the database. The LinqDataSource control makes LINQ available to Web developers through the ASP.NET data-source control architecture.

The LinqDataSource control creates the code for selecting, inserting, updating, and deleting objects in the database. These classes can be called by business logic to perform database functions and apply business-logic rules.

To create and configure a LinqDataSource control

Open or switch to the Default.aspx page.

Switch to Design view.

From the Data tab of the Toolbox , drag a LinqDataSource control onto the Web page.

You can leave the ID property as LinqDataSource1.

In the LinqDataSource Tasks smart tag panel, click Configure Data Source .

In the context object list, select TasksDataContext and then click Next .

In the list, select TasksLists(Table<TasksList>) , and then click Finish .

In the LinqDataSource Tasks smart tag panel, select the Enable Delete , Enable Insert , and Enable Update check boxes.

Save the page.

Notice that you did not have to specify any database commands for selecting the data.

Creating and Configuring a GridView Control

To create a user interface for the data that is made available by the LinqDataSource control, you can use various data controls. In this walkthrough you will add a GridView control to the page in order to view, update, and edit the data in the TasksList table.

To create and configure a GridView control

In the Default.aspx page, switch to Design view.

From the Data tab of the Toolbox , drag a GridView control onto the Web page

In the GridView Tasks smart tag panel, select LinqDataSource1 as the data source. (If you assigned a different name when you created the LinqDataSource control, use that name.)

In the GridView Tasks smart tag panel, select the Enable Editing and Enable Deleting options.

Press CTRL+F5 to run the page.

The page displays the data that you entered previously in the walkthrough, and it enables you to edit or delete rows.

This walkthrough has illustrated how to create the data-access and business-logic layer of an application by using the LINQ to SQL Classes template and the LinqDataSource and GridView server controls. You created a way for Web site pages to access data that is flexible and that is not directly tied to the presentation layer of the Web site.

The topic Walkthrough: Creating an Ajax-Enabled Data Application uses the LinqDataSource control to create an AJAX-enabled Web application that displays and updates information in the Tasks database.

Walkthrough: Creating an Ajax-Enabled Data Application

ASP.NET Walkthroughs by Scenario

Additional resources

  • 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

Related Articles

  • Measures of Query Cost in DBMS
  • What is EII(Enterprise Information Integration)?
  • Hardware RAID
  • Business-Logic Layer
  • Audit Trail
  • Virtual Private Database (VPD)
  • Predicate Locking
  • What is Report Generator?
  • What is Software RAID?
  • Difference Between Data Mining and Data Analysis
  • Query-Execution Plan in SQL
  • Weak Levels of Consistency
  • Difference Between Hardware RAID vs Software RAID
  • Introduction to NoSQL Cloud Database Services
  • Double Buffering
  • Failure Classification in DBMS
  • ODBS Full Form
  • Access Types in DBMS
  • Strategies For Migrating From SQL to NoSQL Database

Data-Access Layer

In this article, we are going to learn about the Business Logic Layer in Database Management systems . A DBMS usually consists of various layers where each one has a specific kind of task it performs. The main purpose of the layered structure is to implement abstraction in Database systems. Change in one schema must not affect the other schema. This architecture allows the Database Administrator to design the schema and implement methods to allow secured access to the stored data.

The Data-Access Layer (DAL) is a component of a software architecture that is responsible for managing the data storage and retrieval of an application. It sits between the business-logic layer and the data storage system and provides an abstraction layer that allows the business-logic layer to interact with the data storage system without being aware of its specific implementation.

The DAL is responsible for performing tasks such as: -Connecting to the data storage system and managing the connection. -Generating and executing SQL queries or other data access commands to retrieve and store data. -Mapping the data from the data storage system to the application’s data objects and vice versa. -Handling errors and exceptions related to data access. -Providing support for transactions and other data access features.

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

The DAL can be implemented using different data access technologies, such as ADO.NET, JDBC, or ORM (Object-relational mapping) libraries. The choice of technology will depend on the specific requirements of the application and the data storage system being used.

In summary, The Data-Access Layer (DAL) is a component of a software architecture that is responsible for managing the data storage and retrieval of an application. It sits between the business-logic layer and the data storage system and provides an abstraction layer that allows the business-logic layer to interact with the data storage system without being aware of its specific implementation. The DAL is designed to be reusable and independent of the business logic and data storage implementation. It can be implemented using different data access technologies and it provides support for transactions and other data access features.

Data-Access Layer (DAL)  

Data-Access Layer is a layer in an application that provides easy and simplified access to data stored in persistent storage, such as an entity-relational database or any database for that matter. It is layer that exists between the Business Logic Layer (BLL) and the storage layer . 

Let us understand some terminologies involved: 

1. Data-Access Object (DAO): They are entities that are collectively known as the Data Access Layer (DAL). A DAL might be a single class, or it might be composed of multiple Data Access Objects (DAOs).  2. Business Logic Layer: The business logic layer consists of all the objects and functionalities which handle the business logic of the application, this is where the main implementation of an application takes place and it is very unique for each application.  3. Storage Layer: The actual database where data is stored, upon which CRUD operations can be performed. This might be some remote or cloud storage.  

Data Access Layer

Data Access Layer

Whenever a specific data query or update is required by the Application (BLL), the request is sent to the Data Access Layer, which then takes appropriate actions to ensure that the requested data or updation is performed, this results in a level of abstraction wherein the Business Layer will only know which function or methods to call, and it does not have to know the actual architecture or details of the entire Database.  

Purpose/Importance of having a DAL:

  • Provides a centralized location from where calls are made onto the database(s).
  • Provides a layer of abstraction as a developer working on the Business Logic need not worry about the way in which data is stored or their CRUD operations.
  • A Data-Access Layer (DAL) can support multiple databases, so the application is able to make use of any database as per its requirement.
  • Because segregating the data access code, enables better maintainability and easy migration of the database.

Example : 

Let us assume an airline ticket reservation system, when a user attempts to view the flight availability from the front-end, the business logic layer will send the query request to the Data-Access Layer, from here its this layer’s job to interact with the storage and obtain the queried results. The Business logic layer is not concerned with the way in which data is represented in the storage, whether it is relational or non-relational types. It is the job of the DAL to retrieve the required data from one or more locations from the storage(s) and send it back to the Business Logic Layer, which is converted to user-understandable format, then sent to the front-end.

Please Login to comment...

  • Computer Subject
  • laxmishinde5t82

Improve your Coding Skills with Practice

 alt=

What kind of Experience do you want to share?

 FourWeekMBA

The Leading Source of Insights On Business Model Strategy & Tech Business Models

business-logic-layer

Business Logic Layer And Why It Matters To Understand Blockchain Business Models

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. 

Table of Contents

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.

Differentiating between business logic and business rules

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. 

A better option is to design the application to support multiple different user interfaces. Code that is common to each user interface then becomes the business logic layer.

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.

Key takeaways:

  • 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.

Read Next:  Proof-of-stake ,  Proof-of-work ,  Bitcoin ,  Ethereum ,  Blockchain .

Related Blockchain Business Frameworks

web3

Blockchain Protocol

blockchain-protocol

Merkle Tree

merkle-tree

Nothing-at-stake

nothing-at-stake-problem

Proof of Work

proof-of-work

Application Binary Interface

application-binary-interface

Proof of Stake

proof-of-stake

Proof of Work vs. Proof of Stake

proof-of-work-vs-proof-of-stake

Proof of Activity

proof-of-activity

Blockchain Economics

blockchain-economics

Blockchain Business Model Framework

blockchain-business-models

Smart Contracts

smart-contracts

Non-Fungible Tokens

non-fungible-tokens

Decentralized Finance

decentralized-finance-defi

History of Bitcoin

history-of-bitcoin

Ethereum Flywheel

blockchain-flywheel

Decentralized Exchange

decentralized-exchange-platforms

  • Business Models
  • Business Strategy
  • Business Development
  • Digital Business Models
  • Distribution Channels
  • Marketing Strategy
  • Platform Business Models
  • Revenue Models
  • Tech Business Models
  • Blockchain Business Models Framework

More Resources

web3

About The Author

' src=

Gennaro Cuofano

Discover more from fourweekmba.

Subscribe now to keep reading and get access to the full archive.

Type your email…

Continue reading

  • 70+ Business Models
  • Airbnb Business Model
  • Amazon Business Model
  • Apple Business Model
  • Google Business Model
  • Facebook [Meta] Business Model
  • Microsoft Business Model
  • Netflix Business Model
  • Uber Business Model
  • Developing Applications with Oracle Visual Builder
  • Manage Applications
  • Test and Debug Applications

Debug Business Objects

Because Visual Builder uses a multi-tier architecture, you might need to debug your application at different levels to identify the root cause of an issue. This might include the business object layer, where data access to and from a client application occurs through REST API endpoints.

While you can use the Network tab in your browser's development tools for external REST APIs, Visual Builder 's built-in tracing and logging mechanisms can help you troubleshoot issues when you create business objects as the data source for your user interface. Because data from a business object is written to the UI via REST APIs, you might want to enable tracing to track the response times of individual REST calls. You can also enable logging to view events triggered by your business rules, in addition to diagnostic messages logged by custom Groovy scripts.

IMAGES

  1. Web Application Architecture Presentation Business Data Layers

    presentation business data access layer

  2. Architecture of Business Layer working with Entity Framework

    presentation business data access layer

  3. Data-Access Layer

    presentation business data access layer

  4. Business Layer Business Components Data Access Components Core Services

    presentation business data access layer

  5. Creating a Business Logic Layer (C#)

    presentation business data access layer

  6. Where to Use Tiers and Layers Graphics in a Presentation

    presentation business data access layer

VIDEO

  1. Principles for Designing Effective Data Access Layer

  2. BUSINESS PLAN PRESENTATION || Business plan presentation discussion || How to make business plan

  3. MVC Design Pattern

  4. Data Manipulation in MS Access

  5. Access denied by Business Data Connectivity

  6. Data Access layer in asp.net mvc C#| DB Context class

COMMENTS

  1. What is Three-Tier Architecture

    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 vs. layer. In discussions of three-tier architecture, layer is often used interchangeably - and mistakenly - for tier, as in 'presentation layer' or 'business logic layer.'

  2. What is the different between Model/Business Layer/Data Access and

    This separate layer is referred to as the Data Access Layer. Business Logic Layer. 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 ...

  3. Architectural Overview

    The data access layer consists of the definitions of database tables and columns and the computer logic that is needed to navigate the database. The layer in the application architecture enforces rules regarding the storage and access of information. For example: All date fields must be valid dates. All numeric fields must never contain ...

  4. architecture

    Nowadays, with modern frontend frameworks such as Angular, React, and Vue, does the entire presentation layer run on client side, and do the entire business logic layer and the entire data access layer run on the server side? Business logic and data access happen on the server side, that is correct. Angular, et.al. handle code on the frontend.

  5. Presentation Domain Data Layering

    Martin Fowler. One of the most common ways to modularize an information-rich program is to separate it into three broad layers: presentation (UI), domain logic (aka business logic), and data access. So you often see web applications divided into a web layer that knows about handling HTTP requests and rendering HTML, a business logic layer that ...

  6. Creating a Business Logic Layer (C#)

    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 ...

  7. Common web application architectures

    The most common organization of application logic into layers is shown in Figure 5-2. Figure 5-2. Typical application layers. These layers are frequently abbreviated as UI, BLL (Business Logic Layer), and DAL (Data Access Layer). Using this architecture, users make requests through the UI layer, which interacts only with the BLL.

  8. .NET Application Architecture: the Data Access Layer

    In the classic three tier design, applications break down into three major areas of functionality: The data layer manages the physical storage and retrieval of data. The business layer maintains business rules and logic. The presentation layer houses the user interface and related presentation code. Inside each of these tiers there may also ...

  9. Creating a Data Access Layer (C#)

    Before we can create our Data Access Layer (DAL), we first need to create a web site and setup our database. Start by creating a new file system-based ASP.NET web site. To accomplish this, go to the File menu and choose New Web Site, displaying the New Web Site dialog box. Choose the ASP.NET Web Site template, set the Location drop-down list to ...

  10. Three Tier Architecture In ASP.NET Core 6 Web API

    Steps to follow for configuring these layers, Add the Class Library project of Asp.net for Data Access Layer. Right Click on the project and then go to the add the new project window and then add the Asp.net Core class library project. After Adding the Data Access layer project now, we will add the Business access layer folder.

  11. Global Three Layer Application Architecture

    Presentation. Business Logic. Data Access. Let's add couple of more guidelines to each of the layer. Presentation layer is not just a user interface - it is an interaction point. ... Service #1 is used from Business Logic to fulfill some of the domain layer's needs, while Service #2 is used from Data Access layer to store specific kinds of data ...

  12. 1. Layered Architecture

    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). ... 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 ...

  13. The Three Layered Architecture. Layers

    The presentation layer is the highest layer of the software. It is where the user interface of the software is placed. It contains logic only related to how the data is presented and the beginning ...

  14. 3 Layered Architecture

    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 ...

  15. #4

    Hi there! Today I'll try to explain you why the BLoC Architecture is the key to building a strong and stable app. So, we'll dive into the Presentation Layer,...

  16. Business-Logic Layer

    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 ...

  17. Walkthrough: Creating the Data Access and Business Logic Layers in ASP

    The recommended approach is to separate the data access logic from the presentation layer. This separate layer is referred to as the data-access layer. The data-access layer can be implemented as a separate Class Library project. However, you can also use tools in Visual Web Developer that can generate a data-access layer for you.

  18. Data-Access Layer

    The Data-Access Layer (DAL) is a component of a software architecture that is responsible for managing the data storage and retrieval of an application. It sits between the business-logic layer and the data storage system and provides an abstraction layer that allows the business-logic layer to interact with the data storage system without ...

  19. Business Logic Layer And Why It Matters To Understand Blockchain

    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 ...

  20. What Are the 5 Primary Layers in Software Architecture?

    Here are five main layers in software architecture: 1. Presentation layer. The presentation layer, also called the UI layer, handles the interactions that users have with the software. It's the most visible layer and defines the application's overall look and presentation to the end-users.

  21. Business layer, presentation layer, Data layer

    It covers what you are asking here. The file with .aspx extension in your case is responsible for rendering a view. So it's categorized as a presentation layer. The second one with .cs extension is looking like it's trying to access the database. So it could be categorized as a data access layer. The business layer make use of your data access ...

  22. Debug Business Objects

    Because Visual Builder uses a multi-tier architecture, you might need to debug your application at different levels to identify the root cause of an issue. This might include the business object layer, where data access to and from a client application occurs through REST API endpoints. While you can use the Network tab in your browser's development tools for external REST APIs, Visual Builder ...

  23. How do I pass data from presentation layer to business logic layer

    I plan on creating an architecture with a Presentation Layer (MVC), a Data Access Layer (DAL), and a Business Logic Layer (BLL). The DAL and BLL will be separate class libraries from the MVC project. The idea is that the MVC project will reference the BLL to perform business logic which will then reference the DAL for interacting with the database.