Doctrine bringt ab Werk ein paar sehr mächtige Attribut-Validatoren auf Anwendungsebene mit, die aber im Symfony-Kontext nur für zusätzlichen Overhead sorgen und gleichzeitig nicht ganz so fein granuliert sind wie bspw. ein entsprechender sfValidator. Wie man Doctrine auf Projektebene konfigurieren und bspw. das Validation-Feature abschalten kann, zeigt das folgende Listing.
Doctrine – Accessoren & Mutatoren
Also erstens, damit man die Doku versteht: Mutatoren sind natürlich “Setter” (setFirstname(string name)), Accessoren “Getter” (getFirstname()). Doctrine ermöglicht es auf vielfältige Weise, Attribute eines OR-Objekts programmatisch zu erfragen bzw. zu verändern. Da jede Instanz von Doctrine_Record letztlich die abstrakte Elternklasse Doctrine_Access implementiert, wird der Zugriff und alle Änderungen durch die (magischen) PHP-Methoden __get(), __set() und __call() koordiniert. Zusätzlich bietet Doctrine eine Konfiguration, die es ermöglicht, jede Änderung an einem Objekt einem optionalen, zentralen Methodenaufruf zuzuleiten, der dann als eine Art Interzeptor fungiert.
Behave, baby!
Doctrine macht es dem Entwickler leicht, seine Object-Models mit Businesslogic anzureichern. Entsprechende Methoden an der Doctrine_Record- – oder allgemeiner – an einer entsprechenden Doctrine_Table-Kindklasse zu verdrahten ist ein Kinderspiel. Irgendwann trifft man dann auf einen Anwendungsfall, der eine entsprechende Zusatzfunktionalität erfordert, ohne dass das “Tätigkeitsfeld” dieser Funktionalität auf nur eine Gruppe von Entitäten zu begrenzen wäre. Anstatt nun die immer gleichen Methoden für alle seine Object-Models, die die neue Funktionalität benötigen, zu implementieren und damit ziemlich viel Code zu produzieren, möchte man lieber das ORM-Framework selbst erweitern. Auch hierfür bietet Doctrine die entsprechenden Schnittstellen: Einen Eventdispatcher zusammen mit ziemlich viele Stellen im Code, denen man “zuhören” kann und das Konzept der Behaviours (dt. etwa Verhaltensmuster): Oh behave!