[PHP] Ein Basis-OR-Mapper für PDO

[PHP] Ein Basis-OR-Mapper für PDO

saftmeister

Nutze den Saft!
saftmeister hat eine neue Ressource erstellt:

[PHP] Ein Basis-OR-Mapper für PDO - Diese Ressource dient zum einfachen Copy&Paste und Verwendung in eigenen Projekten

Diese Klasse ist lediglich inline-dokumentiert. Im Beitrag Prepared Statements Teil 3 wird die Klasse erklärt und man wird auch Beispiele für die Anwendung dort finden.

PHP:
<?php
/**
 * ORM.php
 * 
 * - Provides a basic class for accessing database using ORM technology.
 * 
 * @author saftmeister
 * 
 */
class ORMException extends Exception {}

/**
 * The OR-Mapper class
 *
 * Provides the basic database access functionality
 */
class ORM
{
  private static $dbhost = '127.0.0.1';...

Weitere Informationen zu dieser Ressource...
 

ComFreek

Mod | @comfreek
Moderator
Ein paar weiterführende Gedanken zur Verbesserung (zur Erweiterung der "Basis"):

- ORMException in weitere Exceptionklassen verfeinern.
- Die Tabelle nicht einfach so in den Queries interpolieren. Was ist, wenn eine Tabelle ein SQL-Keyword enthält? Dann müsste es in `Backticks` stehen.
- Nicht auf Attribute der Kindklassen zugreifen, siehe auch meinen anderen Beitrag: https://www.tutorials.de/threads/ph...er-basisklasse-verwenden.399480/#post-2063060
- Die DB-Verbindung unabhängig von der ORM-Klasse zu machen.

Ich habe mir den Code nicht 100% durchgelesen, aber ist nicht ein Fehler in Zeile 426? pkCol ist der Name der PK-Spalte. Wie kann dann das DELETE-Query im WHERE-Teil pkCol=pkCol stehen haben?

---
Daumen hoch auf jeden Fall dafür, dass du dir Zeit nimmst, für Anfänger leichtverständliche Artikel hier für solche Themen bereitzustellen! Natürlich ist es dabei nicht möglich, auf jedes Detail einzugehen, deswegen verstehe nicht Obiges als vollständige Kritik sondern eher als Hinweise.
 

saftmeister

Nutze den Saft!
Das tue ich nicht, vielen Dank für die Hinweise. Mitunter hat man schon mal ein bisschen die Scheuklappen auf, wenn man versucht so ein Thema zu stemmen. Eine "Zurechtweisung" empfinde ich nicht etwa als negativ sondern als Zugewinn.

- Granularere Exceptions sind ein guter Einwand, ich werde da in zukünftigen Beiträgen dran feilen. NoSuchElementException und Konsorten habe ich ohnehin schon auf der Agenta.
- Backticks sind in MySQL ein probates Mittel, um Keywords zu entschärfen. Das gilt aber anscheinend nur für MySQL? Ich werde es mit einbauen, die Basis-ORM-Klasse ist ohnehin noch nicht fertig, ein wichtiges Feature fehlt da ohnehin noch: JOIN.
- Mir ist noch keine bessere Möglichkeit eingefallen, ohne die Modelle an den ORM zu verbandeln. Ich wollte die Modelle lose stehen lassen, und eine umgekehrte DI bauen, was mir durch den Hack erstmal gelungen ist. Wie schon beschrieben, habe ich vor, das auf Reflection umzubauen, aber das kommt später.
- Der ORM ist eine Abstraktions-Schnittstelle für PDO und deshalb auch so eng damit verheiratet. Man könnte da aber durchaus mit Interfaces arbeiten und ihn so alleinstehend implementieren. Mal schauen, was da alles noch machbar ist.
- Die Zeile baut das Query für den Delete auf Basis eines Prepared Statement mit Bezeichner zusammen. Der Namen der Primärschlüsselspalte wird gleichzeitig als Bezeichner verwendet. Beispiel:

PHP:
$pk = 'id';
$this->table = 'users';
$query = sprintf("DELETE FROM %s WHERE %s = :%s", $this->table, $pk, $pk);

echo $query;

--
// 'DELETE FROM users WHERE id = :id'

Dann wird über bindValue() der Bezeichner :id wieder an den Wert der Property aus getId() gebunden.
 

ComFreek

Mod | @comfreek
Moderator
Das gilt aber anscheinend nur für MySQL?
Anscheinend schon.

Die Zeile baut das Query für den Delete auf Basis eines Prepared Statement mit Bezeichner zusammen. Der Namen der Primärschlüsselspalte wird gleichzeitig als Bezeichner verwendet.
Ich hatte diesen kleinen Doppelpunkt überlesen ;)

Vielleicht möchtest du auch die Nachteile von DAOs erwähnen:
Wikipedia (en)/Data access object/Disadvantages hat gesagt.:
Potential disadvantages of using DAOs include leaky abstraction[citation needed], code duplication,[2] and abstraction inversion. In particular, the abstraction of the DAO as a regular Java object can the high cost of each database access, and can also force developers to trigger multiple database queries to retrieve information that could otherwise be returned in a single operation with normal SQL set operations.
(Quelle)