PHP OOP: business logic layer - DB layer

what could be a good design for layering between the business logic objects and the Database 开发者_高级运维using OOP?

---

Any of these would work (from Fowler's POEAA):

Data Source Architectural Patterns:

• Table Data Gateway: An object that acts as a Gateway to a database table. One instance handles all the rows in the table.
• Row Data Gateway: An object that acts as a Gateway to a single record in a data source. There is one instance per row.
• Active Record: An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.
• Data Mapper: A layer of Mappers that moves data between objects and a database while keeping them independent of each other and the mapper itself.

Which to choose depends on which of these you picked (same source):

Domain Logic Patterns:

• Transaction Script: Organizes business logic by procedures where each procedure handles a single request from the presentation
• Domain Model: An object model of the domain that incorporates both behavior and data
• Table Module: A single instance that handles the business logic for all rows in a database table or view.
• Service Layer: Defines an application's boundary with a layer of services that establishes a set of available operations and coordinates the application's response in each operation.

In general, the more closely your business objects resemble the DB schema and is centric around CRUD operations, the simpler your Data Source Architectural and Doman Logic pattern can be (it doesnt have to though). If you find yourself with a lot of Impedance Mismatch or with lots of Business Logic not directly related to the DB data, then you might opt for Domain Model / Data Mapper (and might also include an ORM).

---

There are several approaches you can take with this, but one i'd like to recommend is the DataMapper pattern combined with domain models. See this page for more information.

This way you seperate your data access from your domain models (business logic) in a good and easy way. If you're a little bit familiar with OOP, the UML model in the page linked above should clarify the way of approach, and how it seperates database logic from business logic.