Lecture
Row Data Gateway Design Pattern
The object acts as a gateway to a separate record in the data source. One copy on one record.
Embedding the database access code in objects stored in memory can lead to some inconveniences. First, if your objects contain business logic, adding interaction with the database will increase the complexity. Soon, testing will become inconvenient if objects stored in memory are tied to the database. Tests will become slower due to access to the database.
The object of the gateway to the record is represented exactly as a record in the database, but it also allows access through regular means of the programming language. All details of access to the database are hidden behind this interface.
Example: the PersonGateway gateway object, record data from the person table, and insert and update methods that allow you to work with the record transparently.
High-quality implementation of this pattern for PHP exists in particular in the Zend Framework in the class Zend_Db_Table_Row
Active Record Design Pattern
One object controls both data and behavior. Most of this data is permanent and should be stored in the database. This pattern uses the most obvious approach — storing the data access logic in an entity object.
The object is a "wrapper" of a single line from a database or view, it includes access to the database and data handling logic.
Example: the Worker object contains data about one worker and the methods: add, update, or delete. Among other things, a separate method renamed name.
Table Data Gateway Design Pattern
The object acts as a gateway between the data in the application and in the database. One object works immediately with all entries in the table.
The combination of SQL queries and application logic can cause quite a lot of problems. There are developers who are not strong in SQL, but there are those who have succeeded in this. SQL server administrators should be able to quickly find the SQL code in order to understand how to set up and develop the server.
The gateway object to the table contains all SQL queries for accessing a single table or view (view): fetch, update, insert, delete (CRUD). The rest of the code, for interacting with the database, refers to the methods of the gateway object.
Example: the PersonGateway gateway object contains methods for accessing the person table in the database. Methods contain SQL code for fetch, insert, update, and delete. The object may contain a special selection, such as a search by company.
Data Mapper Design Pattern
Object and relational databases use different ways to structure data. Many constituent objects, such as collections and inheritance, are not represented in relational databases. When designing an object model with a large number of business logic, it is useful to apply such mechanisms to improve the organization of data storage and the logic that works with them. This leads to differences in organization. So the object and relational schemas are not identical.
However, the need for data exchange between the two schemes does not disappear, and this exchange becomes, in turn, difficult. If the object knows about the relational structure, changes in one of the structures will lead to problems in the other.
Data Mapper is a software layer that separates the object and the database. His duty is to transfer data between them and isolate them from each other. When using a Data Mapper, objects do not need knowledge of the existence of a database. They do not need SQL code, and (of course) information about the structure of the database. Since the Data Mapper is a type of Mapper pattern, the Mapper object itself is unknown to the object.
Comments
To leave a comment
Web site or software design
Terms: Web site or software design