Symfony2 kernel multiplo?

Question

Ho un'applicazione con sito Web principale, API e area amministrativa. Volevo sapere se è una cattiva idea avere tutto in un'unica app o dovrei creare un progetto Symfony2 diverso o dovrei dividerli in kernel diversi?

Non sono sicuro che l'aggiunta di molti pacchetti sullo stesso kernel influirà molto sulle prestazioni o è solo un po ', cosa non importa?

seguito sono riportate le opzioni:

1. tenere tutto sullo stesso kernel, non ci vorrà fare molta differenza
2. hanno kernel multiplo per diverse parti di applicazione (API, admin e sito core)
3. creare Symfony2 diverso progetto per area amministrativa e API.
4. o le vostre sagge parole :)

Answer 1

È possibile definire più "ambienti".

Ad esempio:

In AppKernel.php

public function registerBundles() 
    { 
     $bundles = array(
      new Symfony\Bundle\FrameworkBundle\FrameworkBundle(), 
      new Symfony\Bundle\SecurityBundle\SecurityBundle(), 
      new Symfony\Bundle\TwigBundle\TwigBundle(), 
      new Symfony\Bundle\MonologBundle\MonologBundle(), 
      new Symfony\Bundle\SwiftmailerBundle\SwiftmailerBundle(), 
      new Doctrine\Bundle\DoctrineBundle\DoctrineBundle(), 
      new Sensio\Bundle\FrameworkExtraBundle\SensioFrameworkExtraBundle(), 
      //new AppBundle\AppBundle() 
     ); 

     if (in_array($this->getEnvironment(), array('api'), true)) { 
      $bundles[] = new ApiBundle\ApiBundle(); 
      //-- Other bundle 
     } 
     //-- Other environments 


     return $bundles; 
    } 
} 

Answer 2

E 'una scelta personale, ma ho un progetto simile e ho una publicBundle, adminBundle e apiBundle tutto all'interno dello stesso progetto.

Il colpo di prestazioni extra è negliable ma l'organizzazione è la chiave ... è per questo che stiamo utilizzando un pacchetto MVC (Symfony), in primo luogo, non è vero? :)

NB: la terminologia è un po 'confusa, penso che per Kernel intendi Bundle.

Answer 3

Dipende principalmente dalla qualità dei pacchi. E questo quanto sono connessi.

Rifiuterei il punto 3 all'inizio (create different Symfony2 project for admin area and api.), poiché probabilmente non si creano due applicazioni separate.

Avere kernel multiplo per diverse parti di applicazione (API, admin e il sito di base)

problema comune è creato da ascoltatori e servizi in un contenitore. Soprattutto quando il listener dovrebbe funzionare solo in uno dei contesti dell'app (api/frontend/backend). Anche se ti ricordi di controllarlo all'inizio del metodo listener (e fai magie solo nel contesto desiderato), l'ascoltatore ancora può dipendere dai servizi iniettati che devono comunque essere costruiti e iniettati. Un buon esempio qui è FOS/RestBundle: anche se si configura zones quindi ancora su frontend (quando view_listener è attivato per API) view_handler viene inizializzato e iniettato nell'ascoltatore - https://github.com/FriendsOfSymfony/FOSRestBundle/blob/master/Resources/config/view_response_listener.xml#L11 Non sono sicuro per il 100% qui ma anche disabilitando le traduzioni e il ramoscello (ecc.) per API (la maggior parte delle API non ne ha bisogno) lo accelera.

La creazione di un kernel separato per il contesto dell'API risolverebbe questo problema (nel nostro progetto utilizziamo un kernel e abbiamo dovuto disabilitare quel listener, poiché i profili di blackfire.io ci dicevano che salva ~ 15ms su ogni richiesta frontata).

La creazione di un nuovo kernel per API garantisce che nessuno dei servizi/ascoltatori solo dell'API non interferisca con il rendering di frontend/backend (funziona in entrambi i modi). Ma creerà per te un ulteriore lavoro di creazione di components condiviso in molti pacchetti all'interno del progetto (quelli provenienti da diversi kernel) - ma nel mondo con il compositore non è più un compito enorme.

Ma è il caso solo per le persone che misurano ogni millisecondo di tempo di risposta. E dipende dalla qualità dei pacchetti/3dparty.Se tutto è perfettamente a posto, non è necessario pasticciare con i Kernel.

Answer 4

Alcuni kernel potrebbero non essere necessariamente d'aiuto.

Dividi la tua applicazione in bundle e conserva tutti i vantaggi della condivisione delle tue entità (e così via) attraverso le diverse parti della tua applicazione.

È possibile definire routing/controller/configurazione separati caricati in base all'host/url.

Nota:

Se avete intenzione di separare la vostra applicazione in due grandi fasci (vale a dire Admin & API), e che i due condividono le stesse entità, si avranno sicuramente a fare una scelta.

Questa scelta potrebbe comportare che uno dei bundle contenga troppe (e non correlate) logiche e dovrà essere successivamente refactored in diversi pacchetti.

Creare un pacchetto per sezione dell'applicazione che corrisponde a un set di risorse correlate e fare la differenza tra le due parti attraverso diversi contesti dalla configurazione.

Inoltre, denominare le classi/spazi dei nomi in modo sensato.