I often need to present a more practical view of the classical application partitioning
Presentation Layer -> Business Logic Layer -> Data Access Layer
I believe the diagram below depicts a clear if simplified representation of the interaction between layers.
The key tenant is that there is no SQL or ADO.NET data access code beyond the Data Access Layer (DAL). The DAL provides all data services to the higher level layers. In the cases where the where the business logic is hosted within the physical database the DAL provides a pass-through interface to expose the business logic to the business layer.
With in the database a similar logical partitioning is maintained restricting the DAL from directly accessing the underlying tables. Within the database it self this is relaxed and both the database access code and business code have direct access to the tables.
The two bars cutting across the layers Business Entities and Data Entities represent the data container classes that transport data and user service request arguments between the layers.
While the data entities represent basic entities within the system, the business entities are represent more complex aggregates of the data entities required to complete an autonomous business function. For example to save a customers application for an account could be broken down into the following. For simplicity this explanation forgoes the actual business logic involved in processing an application and focuses on storing the application.
The class definitions are simplified pseudo-code of entity classes
Data Entities
class ApplicationEntity
class CustomerEntity
class AccountEntity
Business Entity
class AccountApplicationEntity
{
ApplicationEntity ApplicationDetails;
CustomerEntity CustomerDetails;
AccountEntity AccountDetails;
}
Data Service Interface
SaveApplication(ApplicationEntity entity); // Saves the data in the Applications table
SaveCustomer (CustomerEntity entity); // Saves the data in the Customers table
SaveAccount(AccountEntity entity); // Saves the data in the Accounts table
Business Service Interface
SaveAccountApplication(AccountApplicationEntity entity)
{
DataService ds = new DataServiceInterface();
ds.SaveApplication(entity.ApplicationDetails);
ds.SaveCustomer(entity.CustomerDetails);
ds.SaveAccount(entity.AccountDetails);
}
You can assume that the data access is in a transaction.
From the consumer’s point of view creating an application is a matter of instantiating an instance of the AccountApplicationEntity and populating the ApplicationDetails, CustomerDetails and the AccountDetails, then invoking the business service for further processing.