2011-02-10 18 views
11

Utilizzerò entity_manager nel mio modello. Ma entity_manager è disponibile solo nel controller: throw $em = $this->get('doctrine.orm.entity_manager'). Quindi, devo definire i metodi del modello con il parametro $em. Ciò rende difficile il test phpUnit e viola la struttura dell'applicazione. Ad esempio:Symfony2 entityManager nel modello

class Settings 
{ 
    public static function getParam($em, $key) 
    { 
     $em->createQuery(" 
      SELECT s 
      FROM FrontendBundle:Settings s 
      WHERE s.param = {$key} 
     "); 
     return $em->getResult(); 
    } 
} 

Esiste un approccio per utilizzare il servizio entity_manager nella sezione del modello?

risposta

8

query nella classe Entity

Mettere query in voi entità sembra strano per me. Allo stesso modo di inserire query nella classe del modello in Doctrine 1 non è considerata una buona pratica. Le classi di entità dovrebbero essere leggere.

In realtà sto imparando Doctrine2 e stavo pensando a un problema simile: dove inserire le query?

In Dottrina 1 ci sono classi tavolo speciale e mi aspettavo qualcosa di simile in Dottrina 2.

Pattern Repository

Oggi ho imparato che Doctrine 2 utilizza il Pattern Repository: http://www.doctrine-project.org/docs/orm/2.0/en/reference/working-with-objects.html#custom-repositories

Tuttavia, per recuperare un'istanza della classe repository è necessario utilizzare Entity Manager. In un modo o nell'altro ne hai bisogno.

Tuttavia, seguire il modello di repository sembra una scelta migliore.

A mio parere Se si insiste per avere il metodo di query nella classe Entity, è necessario passare ad esso un Entity Manager.

Testing

Perché la necessità di passare entity manager rende difficile da testare? Dalla mia esperienza, le dipendenze esplicite rendono i test più facili in quanto puoi controllarli nel test (e prenderli in giro per esempio).

D'altra parte passare il gestore di entità ad ogni metodo non è la scelta giusta. In tal caso renderei la dipendenza obbligatoria e aggiungerla al contructor.

14

In primo luogo, una nota di partenza: per convenzione la classe Entity dovrebbe essere probabilmente singolare. Quindi, Impostazione, non Impostazioni. Si potrebbe sostenere che le "impostazioni" come gruppo di impostazioni correlate potrebbero essere viste come un'unica entità. Ancora, qualcosa da tenere a mente.

In Doctrine2, si utilizzerà un repository per creare questo tipo di query. Nel tuo codice in cui avevi intenzione di chiamare Settings::getParam, dovresti invece recuperare il repository e interrogarlo. In Symfony2, dicono:

// $em is your entitymanager, as you were going to pass to your method above 
// $key is the key you were going to pass to your method above 
$repository = $em->getRepository('\FrontendBundle\Settings'); 
$setting = $repository->getByParam($key); 

Per impostazione predefinita, senza scrivere codice, depositi definiscono getByXXXX per ogni campo nella vostra entità.

Se si desidera eseguire una query più complessa, è possibile estendere il repository.

use Doctrine\ORM\EntityRepository; 

class SettingsRepository extends EntityRepository 
{ 
    public function getBySomeComplicatedQuery() { 
     $sort_order = $this->getEntityManager() 
      ->createQuery('SELECT count(s) FROM FrontendBundle\Settings s WHERE s.value > 32') 
      ->getResult(Query::HYDRATE_SINGLE_SCALAR); 
    } 

} 

E quindi si chiama quel metodo allo stesso modo.

Altri sostengono l'uso di un oggetto Manager che non sarebbe quindi legato all'Entità/ORM, ma questa è una complicazione inutile in questo caso, penso.

Doctrine2 è specificamente progettato per non consentire l'utilizzo di query nel file Entity; Entità ed EntityManager sono in realtà due aspetti del livello standard del modello, divisi per applicare le migliori pratiche. Vedi questo articolo: http://symfony2basics.jkw.co.nz/get-symfony2-working/entities/

+0

Ciao, l'ultimo collegamento è andato. – userfuser

Problemi correlati