Application Layering

There is very famous law on Application Layering in Object Oriented World called Law of Demeter (LoD). The wikipedia definition for the same is.

The Law of Demeter (LoD) or principle of least knowledge is a design guideline for developing software, particularly object-oriented programs. In its general form, the LoD is a specific case of loose coupling. This can be succinctly summarised in one of the following ways:

  • Each unit should have only limited knowledge about other units: only units “closely” related to the current unit.
  • Each unit should only talk to its friends; don’t talk to strangers.
  • Only talk to your immediate friends.

All well performing and successful applications use a layered design. A layered design separates the technical responsibilities of an application into cohesive parts that isolate the implementation details of a particular technology or interface.

Below diagram shows a high-level view of a typical layering strategy that is useful for many business applications.

Application Layers

Application Layers

The above layered approach ensures that the dependency flows only in one direction and avoids the typical “spaghetti code” that is common of applications designed without layers.
The persistence layer sits between the business logic layer of the application and the database. This separation is important to ensuring that your persistence strategy is not mixed with your business logic code, or vice versa. The benefit of this separation is that your code can be more easily maintained, as it will allow your object model to evolve independently of your database design.

Lets discuss briefly the roles & responsibilities of each layer.

The Business Object Model

The business object serves as the foundation for the rest of the application. It is the object-oriented representation of the problem domain, and therefore the classes that make up the business object model are sometimes called domain classes. All other layers use the business object model to represent data and per- form certain business logic functions.

Application designers usually start with the design of the business object model before anything else. Even if at a very high level, the classes are identified by deriving them from the nouns in the system. For example, in a bookstore application, the business object model might include a class called Genre with instances like Science Fiction, Mystery, and Children’s. It might also have a class called Book with instances such as Spring In Action, Effective Java, and Patters of Enterprise Architecture.

Business object model classes may contain some logic as well, but they should never contain any code that accesses any other layer, especially the presentation and persistence layers. Furthermore, the business object model should never depend on any other layer. Other layers use the business object model—it’s never the other way around.

A persistence layer like Hibernate/TopLink will generally use the business object model for representing data that is stored in the database. The domain classes of the business object model will become the parameters and return values of the persistence methods. It is for this reason that these classes are sometimes referred to as Data Transfer Objects (DTOs). Although data transfer is not their only purpose, it is a fair name from the perspective of a persistence framework.

The Presentation Layer

The Presentation Layer is responsible for displaying application controls and data to the end user. It is responsible for the layout and formatting of all information. The most popular presentation approach in business applications today are web front ends that use HTML and JavaScript to provide a look and feel to the user via a web browser.Web applications have the advantage of cross-platform compatibility, ease of deployment, and scalability. Rich clients that use native operating system widgets like tabs, tables, tree views, and embedded objects are preferred. Rich clients allow for a much more powerful user interface, but are somewhat more difficult to deploy. In todays world Mobile Applications written on iOS, Android and Windows are gaining more and more popular. Many Presentation Libraries/Frameworks now support Responsive Features where the same page can be displayed on any screen i.e. on Tablet/Phone or Desktop Monitor

The Business Logic Layer

The Business Logic Layer of the application describes the coarse-grained services that the application provides. For this reason they are sometimes called service classes. At a high level, anyone should be able to look at the classes and methods in the business logic layer and understand what the system does. For example, in a banking application, the business logic layer might have a class called TellerService, with methods like openAccount(), deposit(), withdrawal(), and getBalance(). These are very large functions that involve complex interactions with databases and possibly other systems. They are much too heavy to place into a domain class, as the code would quickly become in cohesive, coupled, and generally unmanageable. The solution is to separate the coarse-grained business functions from their related business object model. This separation of object model classes from logic classes is sometimes called noun-verb separation.

Object-oriented purists might claim that this design is less object oriented than having such methods directly on the related domain class. Regardless of what is more or less object oriented, it is a better design choice to separate these concerns. The primary reason is that business functions are often very complex. They usually involve more than one class and deal with a number of infrastructural components, including databases, message queues, and other systems. Furthermore, there are often a number of domain classes involved in a business function, which would make it hard to decide which class the method should belong to. It is for these reasons that coarse-grained business functions are best implemented as separate methods on a class that is part of the business logic layer.

The Persistence Layer

The Persistence Layer is where Persistence Frameworks such as Hibernate/TopLink fits in. In an object-oriented system, the primary concern of the persistence layer is the storage and retrieval of objects, or more specifically the data stored in those objects. In enterprise applications persistence layers usually interact with relational database systems for storing data, although in some cases other durable data structures and mediums might be used. Some systems may use simple comma-delimited flat files or XML files. Because of the disparate nature of persistence strategies in enterprise applications, a secondary concern of the persistence layer is abstraction. The persistence layer should hide all details of how the data is being stored and how it is retrieved. Such details should never be exposed to the other layers of the application. We can separate the persistence layer into three basic parts: the abstraction layer, the persistence framework, and the driver or interface.

I hope this has been useful for you and I’d like to thank you for reading. If you like this article, please leave a helpful comment and share it with your friends. 


  1. By Vengat


    • By Manjunath Sampath


Leave a Reply

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