As database people we sometimes forget, or choose to forget, about the application which connects to our database platform. When we had simple two tier apps which connected to the database it was a pretty simple concept, application and database. When n-tier systems came in we saw a web server layer sit between the user and the database, perhaps sometimes called an application tier.
Today as a Solution Architect I often talk with developers and get them to take me through the application they’ve developed. They take me on a journey through its different components and we often hear terms such as presentation tier, application tier, business logic, service bus etc used. However, delving deeper under the .net development hood there’s a much wider collection of terms describing an array of application stack components which link together to make “the app”. While not a comprehensive glossary, hopefully this article will give some insight into that terminology.
To accompany this article I have a diagram available here.
Layer vs. Tier
Until recently I thought these terms were inter-changeable with each other, however to developers a layer is a logical container of specific functionality, for example the presentation layer, the data storage layer etc. Tier however represents the physical location where layers are deployed. For example, a presentation tier may host just the presentation layer, while the application tier hosts the business logic layer, the services layer and the data access layer.
Coupling and Cohesion
Today developers aim to make as much of their code autonomous, reusable and independent. They do this by making their components highly cohesive; the more cohesive something is, the more autonomous it is. When these highly cohesive components need to interact with each other the aim is to make them as loosely coupled as possible, that is they have as little dependence on each other as possible, the looser the coupling, the higher the latency between them can be tolerated, which is great as we move to a SaaS era.
This layer should look after just the user interface, displaying the application to the end user, either through Silverlight, XAML, Win Forms or ASP.net etc. The only code here should be for personalising the visual experience, not performing business logic.
This separates layers to make sure interaction between any two is controlled, manageable and where required, reliable and secure. Service Oriented Architectures are far more than just having a services layer, however this is where it starts for SoA solutions.
Business Logic Layer
This is what could be summarised as the application layer by some, it’s here that the business entity model is defined and maintained, along with business rules and processes. Everything but the presentation and data access logic should be executed in this layer, along with the controls to any external services which the application requires. This layer should also manage and enforce user access security.
Data Access Layer
This layer, sometimes very small, abstracts the business logic layer even further away from how the data layer operates. Here business objects defined in the BLL are mapped to database fields. Additionally, by abstracting the BLL from the data layer multi-vendor database support can be introduced making the application itself database platform portable. ORMs, object relationship mappers, are an increasingly popular and functionally rich tool for mapping business objects to database fields and tables. Oddly(?), this is now sometimes where transaction and concurrency handling is defined, outside of the data layer….
Ideally, just responsible for create, read, update, delete (CRUD) operations, ensuring data operations remain consistent. Once written to the database the data layer is responsible for ensuring it remains persistent and durable.
Disclaimer : This is only my view, millions of devs might argue, feel free!