Überschreiben des JsonModels – Automatische Konvertierung von Entities in Json gerechte Arrays

Heute habe ich die Klasse Zend\View\Model\JsonModel etwas erweitert um meine Entities automatisch in für das JsonModel benötigte Array umzuwandeln. Dies geschieht mit ein Paar einfachen Zeilen im neuen JsonModel


<?php
namespace Vico\ViewModel;

use Zend\View\Model\JsonModel as ZendJsonModel;
use Vico\Entity\BaseEntity;
/**
 * User: Christian Zellot
 * Date: 11.06.13
 * Time: 17:58
 */

class JsonModel extends  ZendJsonModel{

    /**
     * Erweitert den Konstruktor um die Fähigkeit Entity Klassen automatisch in Arrays umzuwandeln
     * @param  null|array|Traversable $variables
     * @param  array|Traversable $options
     */
    public function __construct($variables = null, $options = null)
    {
        $variables_copy = array();
        if($variables != null && is_array($variables)){
            foreach($variables as $variable){
                $variables_copy[] = BaseEntity::isSubclass($variable) ? $variable->toArray() : $variable;
            }
        }
        parent::__construct($variables_copy, $options);
    }

}

Außerdem habe ich das Base Entity um eine statische Methode erweitert, um diese Subklassen von sich erkennen zu lassen, dies geschieht einfach mit der Methode isSubclass($object)


<?php
namespace Vico\Entity;
use Doctrine\ORM\Mapping as ORM;
/**
* User: Zelle
* Date: 24.12.12
* Time: 12:22
*
* Base entity class from which all entities should inherit
*
*/
abstract class BaseEntity {

    /**
     * creates an array based on all fields of the entity
     * @return array
     */
    abstract public function toArray();

    /**
     * sets all fields with data out of the array, there is no checking off violations necessary
     * @param array $data
     * @return void
     */
    abstract public function fillWithArray(array $data);

    /**
     * checks if the given variable is an subclass of BaseEntity
     * @param $object
     * @return bool
     */
    public static function isSubclass($object){
        return is_subclass_of($object, __CLASS__);
    }
}

Dies bietet mir jetzt die Möglichkeit dem JsonModel ein Array mit Entities zu übergeben und diese werden automatisch in das passende Format gebracht. Lästige Umwandlungen in Arrays kann man sich also dadurch leicht ersparen.

Doctrine2 Subquerys und der IDENTITY Helfer

Vor allem bei Suchquerys kommt man oft nicht an Subquerys vorbei. Konkretes beispielsweiße ist hier die Suche nach Einträgen mit gewissen Tags im AAUShare System. Es gibt hier das Post Entity mit den Mappings zu den Tags, bzw PostTags(Mapping zwischen Tags und Posts). Um hier z.B. alle Posts zu erhalten die mit einen Tag besitzen ist noch recht unkompliziert, möchte man jedoch nur Posts mit z.B. den Tags Informatik und ESOP so wird die Query schon komplizierter. Ich habe dazu folgende Methode implementiert:


public function findByTagTitles(array $tags, $additive){
        $tagtsrings = '';
        $logicalop = 'OR';
        if($additive == true){
            $logicalop = 'AND';
        }
        //create query statement ors and ands
        for($i=0; $i<sizeof($tags); $i++){
            $tagtsrings .= ' p.id IN (SELECT IDENTITY(pt'.$i.'.post) FROM AAUShare\Entity\PostTag pt'.$i.' JOIN pt'.$i.'.tag t'.$i.' WITH t'.$i.'.title LIKE :tag'.$i.')';
            if(($i+1) < sizeof($tags)){ //last and or or
                $tagtsrings .=' '.$logicalop;
            }
        }
        if(sizeof($tags)==0){
            $tagtsrings.='1';
        }
        //
        $querystring = 'SELECT p FROM AAUShare\Entity\Post p WHERE'.$tagtsrings;
        $query = $this->getEntityManager()->createQuery($querystring);
        //bind
        for($i=0; $i<sizeof($tags); $i++){
            $query->setParameter('tag'.$i, $tags[$i]);
        }
        //do query
        return $query->getResult();
    }

Hier wird ein Array mit Tags übergeben, nach welchen gesucht wird, der zweite Parameter bestimmt ob die Tags mit „AND“ oder mit „OR“ verknüpft werden. Interessant sind hierbei vor allem die for-Schleifen. In der ersten werden die Tags in Subquerys gepackt und geprüft ob der Post in der Menge der zurückgelieferten postids vorhanden ist. Wichtig ist hierbuach der IDENTITY Befehl für Doctrine2, damit wird auf den Foreign Key der OneToMany Relation in PostTag zugegriffen. Außerdem werden die Subquerys durchnummeriert und auch damit die Parameter

In der zweiten for-Schleife werden die durchnummerierten Query Parameter noch mit den Werten aus den Tags verknüpft.

Neu anlegen von vorhanden Entities by ManyToOne Relationen, obwohl Entity bereits existiert

Heute bin ich auf ein im ersten Moment doch sehr seltsames Verhalten von Doctrine2 gestoßen. Benutzt man verschiedene Entity Manager innerhalb einer Applikation, so beispielsweise bei einer ManyToOne Relation versucht das hinzugefügte Entity neu anzulegen

  /**
     * @ORM\ManyToOne(targetEntity="User", inversedBy="user")
     * @ORM\JoinColumn(name="userid", referencedColumnName="id")
     */
    protected $createdFrom;

Ursache sind wie bereits erwähnt die beiden verschiedenen EntityManager Instanzen. Abhilfe schafft hier logischerweiße das verwenden von der gleichen Instanz, oder aber das Entity aus dem EntityManger neu zu laden mit dem der Speichervorgang durchgeführt werden soll. Wichtig ist jedoch hier zu beachten, das man keine inkonsistenzen schafft wenn man beide EntityManager verwendet!

Anbei noch der Link zu den Stackoverflow Beitrag, der mir hier weitergeholfen hat.

AAUShare – Teile Lösungen und Skripten

Ein Studienkollege hat mich auf eine gute Idee für ein neues Wochenendprojekt gebracht. Es handelt sich um eine Online Plattform in welcher Studenten ihre Skripten teilen können. Man sollte sich dort einfach einloggen können und Skripten und Lösungen hochladen können bzw. nach diesen Suchen können.

Ein solches System müsste mit wenig Tabellen auskommen können. Die Datenbank besteht hauptsächlich aus der Tabelle Post – Ein Eintrag mit einen Titel, Text, Files und Tags sowie einen Rating – welcher in mehrere Tabellen aufgespalten worden ist. Es sollen pro Eintrag mehrere Files hochgeladen werden können, sowie ein Rating möglich sein. Um missbrauch zu vermeiden sollte man als User nur einmal pro Beitrag abstimmen können. Um dies zu gewährleisten muss ein Loginbereich geschaffen werden. Dies sollte mit Sozialen Netzwerken schaffbar sein, da heutzutage fast jeder einen Account in einen der Netzwerke besitzt.
Außerdem sollte man den Post auch Tag’s hinzufügen können um leichter gefunden werden zu können, hierbei habe ich an etwas ähnliches wie bei StackOverflow gedacht, da dies dort meiner Meinung nach einfach und schnell funktioniert.
Eine weitere wichtige Funktionalität ist das Kommentieren von Beiträgen, bzw. die Möglichkeit eine Antwort zu erstellen, wobei es wichtig ist zwischen den beiden zu unterscheiden. Eine Antwort kann wieder ein Beitrag mit Files sein, ein Kommentar sollte jedoch lediglich aus Text bestehen und auch in der Anzeige entsprechend gekennzeichnet werden.

Aufgrund der obigen Funktionalitäten habe ich mir folgendes ER-Diagramm überlegt:

ER

Ich habe hier auch mal das Rating aus dem Post herausgezogen, aus der Überlegung heraus, das für das RatingUpdate nicht auf die Post Tabelle zugegriffen werden muss, ich bin mir aber noch nicht sicher ob das sinnvoll ist.

Als Technologien habe ich ZF2, Doctrine2, Bootstrap (+Font Awesome), JQuery (+Plugins) gewählt, da ich mit diesen das meiset abdecken sollte.

Die Grundstruktur ist gleich wie bei meinen letzten Posts zu Zend / Doctrine. Ein Stolperstein bei den Entities waren die Mappings von Post zu File und Post zu PostTag. Es musste z.B. beim Mapping Post – PostTag auf der PostTag Seite folgendes hinzugefügt werden.


/**
* @ORM\ManyToOne(targetEntity="Post", inversedBy="post")
* @ORM\JoinColumn(name="postid", referencedColumnName="id")
*/
protected $post;

Ein einfaches Mapping auf die postid hat nicht funktioniert, warum genau habe ich nicht herausfinden können.

User Auth

Da die OAuth Lösungen auf die schnell nicht funktionierten habe ich mich Entschieden das Auth Beispiel von https://github.com/samsonasik/SanAuth/ zu modifizieren und an meine Bedürfnisse anzupassen. In dieser Auth wird noch nicht auf Doctrine Entities zurückgegriffen, daher habe ich mithilfe von https://github.com/doctrine/DoctrineModule/blob/master/docs/authentication.md dieses angepasst. Die Anpassungen werde ich in einen anderen Beitrag nochmal genauer erklären.

Nächsten Schritte

Aktuell funktioniert das hochladen von Dateien und das Erstellen von Posts, sowie das einloggen dran. Als nächstes kommen die Kommentare und die Antwortfunktion dran. Außerdem müssen sich noch User registrieren können, dies werde ich über ein Aktivierungsmail lösen. Der nächste Blogeintrag kommt also bald.

DoctrineService und ein BaseEntity

Heute habe ich mir eine Abstrakte Klasse geschaffen für Services geschaffen. Ich habe hierbei alle Funktionalitäten abgebildet die man für die Basis Operationen mit den Entities braucht. Hiermit kann nun einfach aus der Datenbank ein und ausgelesen werden, weiters bietet diese Klasse einen guten Startpunkt für weitere Buisnesslogik und sollte auch als zentraler Zugangspunkt, für den Controller gesehen werden um mit der Datenbank zu kommunizieren. Weiters habe ich in Kombination mit einen einheitlichen Basis Entity die möglichkeit geschaffen die Entities einfach in Arrays umzuwandeln, dies ist vor allem für die Restbasierten Controller gedacht, da diese ja z.B. über JSON Kommunizieren und so lediglich das Array zurückgegeben werden kann ohne sich um die generierung zu kümmern. Angedacht ist dann auch noch den Controller so zu erweitern das er die Basisvalidierung von allen Entities fast fertig vor implementiert und nur mehr spezielle Ausprägungen aus implementiert werden müssen.

Nun aber zum Code, hier erst mal das Service:


<?php
namespace Vico\Service;

use Doctrine\ORM\EntityManager;
use Vico\Entity\BaseEntity;

/**
 * User: Zelle
 * Date: 05.01.13
 * Time: 14:21
 *
 */ 
abstract class DoctrineReadyService{

    /**
     * Returns the name of the class of the entity
     * (represents the name of the entity)
     * should be overwritten in all inheritated classes
     * @return string
     */
    protected function getMainEntityName(){
        return null;
    }

    /**
     *
     * @var Doctrine\ORM\EntityManager
     */
    protected $entityManager;

    public function __construct(EntityManager $em) {
        $this->entityManager = $em;
    }

    /**
     * Sets the EntityManager
     *
     * @param EntityManager $em
     * @access protected
     * @return DoctrineReadyService
     */
    protected function setEntityManager(EntityManager $em)
    {
        $this->entityManager = $em;
        return $this;
    }

    /**
     * Returns the EntityManager
     *
     * Fetches the EntityManager from ServiceLocator if it has not been initiated
     * and then returns it
     *
     * @access protected
     * @return EntityManager
     */
    protected function getEntityManager()
    {
        return $this->entityManager;
    }

    /**
     * Search for an entity with the unique identifier
     * @param $id
     * @return BaseEntity
     */
    public function findById($id){
        $this->checkRepository();
        return $this->getMainRepository()->find($id);
    }

    /**
     * search for an entity with the unique identifier and creates an array out of it
     * @param $id
     * @return array|null
     */
    public function findByIdAsArray($id){
        $entity = $this->findById($id);
        if($entity != null){
            return $this->entityToArray($entity);
        }else{
            return null;
        }
    }

    /**
     * Returns all entities in the database
     * @return BaseEntity[]
     */
    public function findAll(){
        $this->checkRepository();
        return $this->getMainRepository()->findAll();
    }

    /**
    * Returns all entities in the database in form of an array
    * @return BaseEntity[]
    */
    public function findAllAsArray(){
        $this->checkRepository();
        return $this->entitiesToArray($this->getMainRepository()->findAll());
    }

    /**
     * @param $entity
     * @return BaseEntity
     * @throws \Exception
     */
    public function save($entity){
        if(!is_a($entity, $this->getMainEntityName())){
            throw new \Exception("Unexcpected entity class ".$this->getMainEntityName()." ".__CLASS__." ".__METHOD__);
        }
        $this->getEntityManager()->persist($entity);
        $this->getEntityManager()->flush();
        return $entity;
    }

    /**
     * @param BaseEntity $entity
     * @return array
     * @throws \Exception
     */
    private function entityToArray($entity){
        if(!is_a($entity, $this->getMainEntityName())){
            throw new \Exception("Unexcpected entity class ".$this->getMainEntityName()." ".__CLASS__." ".__METHOD__);
        }
        return $entity->toArray();
    }

    /**
     * @param BaseEntity[] $entities
     * @return array
     */
    private function entitiesToArray(array $entities){
        $array = array();
        foreach($entities as $entity){
            $array[] = $this->entityToArray($entity);
        }
        return $array;
    }

    /**
     * @throws Exception
     */
    private function checkRepository(){
        if($this->getMainEntityName() === null){
            throw new \Exception("Entity Name must be set is (".$this->getMainEntityName().") instead");
        }
    }

    /**
     * @return EntityRepository
     */
    private function getMainRepository(){
        return $this->getEntityManager()->getRepository($this->getMainEntityName());
    }

}

Es muss prinzipiell nur getMainEntityName überschrieben werden, damit das Service ordnungsgemäß funktionieren kann. In dieser Methode wird der Name des Entities festgelegt, mit welchen gearbeitet wird.
Ist dieser in der erbenden Klasse nicht gesetzt, so wird eine Exception geworfen um zu verhindern das nicht laufende Services instanziert bzw. genutzt werden. Außerdem wird bei der Methode save überprüft ob das Entity wirklich zu den Service gehört. Prinzipiell könnte zwar jedes Entity gespeichert werden, jedoch sollen die Service explizit nur für das definierte Entity nutzbar sein um so die Rollen für die Datenbankzugriffe klar zu trennen.
Gelöst wurde das hier über eine nicht abstracte Methode die null zurückliefert, ich wollte zwar auch diese abstract machen um so die Erbendeklasse zu zwingen, diese Methode zu überschreiben, jedoch kann dann in der abstrakten Klasse nicht mehr auf dieses Feld zugegriffen werden, deshalb also diese Lösungsvariante.
Das BaseEntity bietet grundsätzlich 2 Funktionalitäten an: eine Methode um ein Array aus dem Entity zu erstellen und eine Methode um aus einen Array ein Entity zu befüllen, wobei lediglich geprüft wird ob das Feld im Array existiert, wenn nicht wird es mit null befüllt. Das Validieren und Filtern sollte hier bereits nicht mehr nötig sein bzw. bereits vorher geschehen.

abstract class BaseEntity {

    /**
     * creates an array based on all fields of the entity
     * @return array
     */
    abstract public function toArray();

    /**
     * sets all fields with data out of the array, there is no checking off violations necessary
     * @param array $data
     * @return void
     */
    abstract public function fillWithArray(array $data);
}

Ein konkretes Service kann z.B. so dazu aussehn


class InstitutionService extends DoctrineReadyService {
    /**
     * Returns the name of the class of the entity
     * (represents the name of the entity)
     * @return string
     */
    protected function getMainEntityName()
    {
        return 'Vico\Entity\Institution';
    }

}

Wie man sieht muss nur mehr der Name zurückgegeben werden und alles sollte funktionieren.

Der nächste Schritt ist nun den Controller dahingehend zu abstrahieren, das nur mehr spezielle Methoden implementiert werden müssen.

Zend Framework 2 – Doctrine – Service Layer

Im Rahmen meiner Bakk. Arbeit verwende ich das Zend Framework 2 + Doctrine 2 Serverseitig. Doctrine 2 bietet ein angenehmes ORM Mapping mit Annotationen (ähnlich dem von Hibernate in der Java Welt).

Jedoch habe ich in den vorhandenen Tutorials und Beispiel Applikationen nur Varianten gesehen, in denen die Queries an die Datenbank über das Repository von Doctrine 2, direkt im Controller stattgefunden haben. Das ist meiner Meinung nach keine schöne Lösung, da so die Business Logik mit Entities direkt im Controller stattfinden würde.
InstituionController mit Repository


class InstitutionController extends DoctrineReadyActionController
{
  /**
   * Institution list action
   *
   * Fetches and displays all institutions.
   *
   * @return array view variables
   */
  public function indexAction()
  {
      $repository = $this->getEntityManager()->getRepository('Vico\Entity\Institution');
      $institutions = $repository->findAll();
      return array(
        'institutions' => $institutions
      );
  }

}

DoctrineReadyActionController ein Controller der die Basisfunktionalität für den EntityManager zur Verfügung stellt

<?php
class DoctrineReadyActionController extends AbstractActionController {
    /**
     * @var EntityManager
     */
    protected $entityManager;

    /**
     * Sets the EntityManager
     *
     * @param EntityManager $em
     * @access protected
     * @return InstitutionController
     */
    protected function setEntityManager(EntityManager $em)
    {
        $this->entityManager = $em;
        return $this;
    }

    /**
     * Returns the EntityManager
     *
     * Fetches the EntityManager from ServiceLocator if it has not been initiated
     * and then returns it
     *
     * @access protected
     * @return EntityManager
     */
    protected function getEntityManager()
    {
        if (null === $this->entityManager) {
            $this->setEntityManager($this->getServiceLocator()->get('Doctrine\ORM\EntityManager'));
        }
        return $this->entityManager;
    }
}

Um dies zu entkoppeln wollte ich einen Service Layer zwischen Doctrine und den Controllern einziehen um. Um Singletons zu vermeiden (Probleme bei der Testbarkeit, etc.. http://stackoverflow.com/questions/1300655/whats-alternative-to-singleton), wollte ich dies mit Dependency Injection lösen, da die Dependency Injection in Zend 2 auch dafür sorgt, das wenn gewollt nur eine Instanz erzeugt wird. Weiters bietet sie z.B. den Vorteil der globalen Konfiguration usw.
Mein erster Ansatz war es eine generelle Service Klasse anzubieten, um so die Grundfunktionalität zu bieten und dann für jedes Entity zumindest ein Service zu erstellen das einen bequem Zugriff auf die Entities bietet. Anzumerken ist hier das durch Constructor Injection der Entity Manager erstellt bzw. hinzugefuegt wird. (Andere Beispiele findet man z.B. hier https://github.com/ralphschindler/Zend_DI-Examples/)


<?php
class DoctrineReadyService implements ServiceLocatorAwareInterface{

    public function __construct(EntityManager $em){
        $this->entityManager = $em;
    }
    /**
     * @var ServiceLocatorInterface
     */
    protected $serviceLocator;

    /**
     * @var EntityManager
     */
    protected $entityManager;

    /**
     * Retrieve serviceManager instance
     *
     * @return ServiceLocatorInterface
     */
    public function getServiceLocator()
    {
        return $this->serviceLocator;
    }

    /**
     * Set serviceManager instance
     *
     * @param  ServiceLocatorInterface $serviceLocator
     * @return void
     */
    public function setServiceLocator(ServiceLocatorInterface $serviceLocator)
    {
        $this->serviceLocator = $serviceLocator;
    }

    /**
     * Sets the EntityManager
     *
     * @param EntityManager $em
     * @access protected
     * @return DoctrineReadyService
     */
    protected function setEntityManager(EntityManager $em)
    {
        $this->entityManager = $em;
        return $this;
    }

    /**
     * Returns the EntityManager
     *
     * Fetches the EntityManager from ServiceLocator if it has not been initiated
     * and then returns it
     *
     * @access protected
     * @return EntityManager
     */
    protected function getEntityManager()
    {
        return $this->entityManager;
    }

}

Da dies jedoch zu Problemen bei der Konfiguration führte und der Aufruf des Service sehr kompliziert wurde


$di = new Di;
      $di->instanceManager()->addTypePreference('Zend\ServiceManager\ServiceLocatorInterface', new \Zend\ServiceManager\ServiceManager());
      $di->instanceManager()->setParameters('Vico\Service\InstitutionService', array("sm"=>$this->getServiceLocator(), "em"=>$this->getServiceLocator()->get('Doctrine\ORM\EntityManager')));;
      

entschied ich mich den weg über den Service Manager zu gehen. Hierbei ist zu betrachten das in der Modul Klasse (Modul.php) folgenden Änderungen durchzuführen sind:

  • Das Interface Zend\ModuleManager\Feature\ServiceProviderInterface ist zu implementieren
  • eine getServiceConfig() Methode ist anzubieten

Die Klasse Module sieht nun wie folgt aus.


<?php
class Module implements ConfigProviderInterface, ServiceProviderInterface
{
    /**
     * Expected to return \Zend\ServiceManager\Config object or array to
     * seed such an object.
     *
     * @return array|\Zend\ServiceManager\Config
     */
    public function getServiceConfig()
    {
        return array(
            'factories' => array(
                'Vico\Service\InstitutionService' => function ($sm) {
                    $entityManager = $sm->get('Doctrine\ORM\EntityManager');
                    return new Service\InstitutionService($entityManager);
                }
            )
        );
    }

    public function getConfig()
    {
        return include __DIR__ . '/config/module.config.php';
    }

    public function getAutoloaderConfig()
      {
        return array(
          'Zend\Loader\StandardAutoloader' => array(
            'namespaces' => array(
              __NAMESPACE__ => __DIR__ . '/src/' . __NAMESPACE__,
              __NAMESPACE__ => __DIR__ . '/src/' . __NAMESPACE__,
                    'Doctrine' => __DIR__ . '/../../vendor/Doctrine'
            ),
          ),
        );
      }
}

Controller:


<?php
class InstitutionController extends AbstractActionController
{
  /**
   * Institution list action
   *
   * Fetches and displays all institutions.
   *
   * @return array view variables
   */
  public function indexAction()
  {
      $service = $this->getServiceLocator()->get('Vico\Service\InstitutionService');
      $institutions = $service->getAll();
      return array(
          'institutions' => $institutions
      );

  }
}

Das Service von dem alle Services erben:

<?php
class DoctrineReadyService{

    /**
     *
     * @var Doctrine\ORM\EntityManager
     */
    protected $entityManager;

    public function __construct(EntityManager $em) {
        $this->entityManager = $em;
    }

    /**
     * Sets the EntityManager
     *
     * @param EntityManager $em
     * @access protected
     * @return DoctrineReadyService
     */
    protected function setEntityManager(EntityManager $em)
    {
        $this->entityManager = $em;
        return $this;
    }

    /**
     * Returns the EntityManager
     *
     * Fetches the EntityManager from ServiceLocator if it has not been initiated
     * and then returns it
     *
     * @access protected
     * @return EntityManager
     */
    protected function getEntityManager()
    {
        return $this->entityManager;
    }

}

Das eigentliche Service des Entities

class InstitutionService extends DoctrineReadyService {

    public function getAll(){
        $repository = $this->getEntityManager()->getRepository('Vico\Entity\Institution');
        return $repository->findAll();
    }

}

Wie man sieht ist dadurch das Aufrufen sehr der Services sehr schmal geworden und durch den ServiceManager wird immer noch die Singleton Funktionalität geliefert, jedoch bin ich mir momentan noch nicht sicher ob dies die sauberste Lösung ist.

Scroll to top