SPL – PS13 Persistence Layer

Overview What is the persistence layer DTO’s and DAO’s Repository ORM

Persistence Layer Assume we have an application that is accessing a DB. If the application access the DB directly, every change in the DB structure, table format or application needs will require changes in several part in the code. Persistence Layer is a design pattern for managing the storing and accessing of permanent data. It manages the communication between the application and the DB and creates a separation between the application logic and the DB access.

Persistence Layer (cont) In order to demonstrate an implementation of the persistence layer, we will review the implementation of an assignment tester. The assignments tester uses a DB with the following tables: students – which includes the id of the student and it’s name. assignments – which includes the number of the assignment, and a string representing the expected output of the assignment. grades – which includes the grade of each student on a specific assignment.

DTO’s and DAO’s The implementation of the persistence layer revolves around 3 types of objects: DTO – Data Transfer Object DAO – Data Access Object Repository

DTO A DTO is an object that represents a record from a single table. It’s variables represents the columns of the table. DTO’s are passed to and from the persistence layer. When passed from the persistence layer to the application logic, they contain data retrieved from the database. When passed from the application logic to the persistence layer, they contain the data that should be written to the database.

DAO These objects contain methods for retrieving and storing DTO’s. In most cases, each DAO is responsible for a single DTO.

Repository In many cases, DTO’s and DAO’s are not sufficient. Since each DAO only knows how to handle a specific DTO, where should we put methods that aren’t related to just a single table? For example: create_tables method Queries that span multiple tables, using join Which DAO should hold these methods? The answer is the repository.

ORM The ORM is a method for mapping between a certain DTO object and it’s related table in a manner that suits any DTO. We use several assumptions for the ORM to work properly: Each DTO class represents a single table. The different DTO classes are obeying the same naming conventions – a class named Foo represents a table named foos. The DTO constructor parameters are the DTO field names and are the columns of the table represented by the DTO.