Now-a-days, many systems are designed with layered architecture, NHibernate also has it and works perfectly well with that design.
A layered architecture divides a system into a number of groups, where each group contains code addressing a particular problem area and these groups are called layers. Most of the enterprise level applications use high-level application architecture that consist of three layers −
For example, a user interface layer which is also known as the presentation layer might contain all the application code for building web pages and processing user input.
One major benefit of the layering approach is that you can often make changes to one layer without any significant disruption to the other layers, thus making the systems lesser fragile and more maintainable.
It is the topmost layer, which contains the code responsible for drawing User Interface, pages, dialogs or screens, and collecting user input, and controlling navigation.
The business layer is responsible for implementing any business rules or system requirements that users would understand as part of the problem domain.
It also reuses the model defined by the persistence layer.
The persistence layer consists of classes and components which are responsible for saving and retrieving application data.
This layer also defines a mapping between the model class and the database. NHibernate is used primarily in this layer.
Every application has a set of helper or utility classes that support the other layers: for example, UI widgets, messaging classes, Exception classes, and logging utilities.
These elements aren’t considered to be layers, because they don’t obey the rules for interlayer dependency in a layered architecture.
It is a high-level view of the NHibernate application and you can also see the simple NHibernate architecture.
The application code uses the NHibernate ISession and IQuery APIs for persistence operations and only has to manage database transactions, ideally using the NHibernate ITransaction API.