La dottrina è un Object Relational Mapper (ORM) che si trova sulla cima di un potente Database Abstraction Layer (DBAL). Quando hai lavorato con Symfony (+ Dottrina) per un po’, sei destinato a Dottrina gli Oggetti del Proxy.

Se hai mai generato un’entità che è associato con un altro soggetto, e di aver preso un occhiata agli argomenti per la funzione associata con entità generato entità file, potreste aver notato l’extra backslash prima il tipo di dichiarazione per l’argomento della funzione. In questo caso, ‘\‘ prima ‘ProxyBundle\Entity\Subjects‘. Se siete come me, si potrebbe avere chiesto rovesciata, e avete bisogno di sapere circa la Dottrina del Proxy di Oggetti di capire il suo scopo.

In generale, giorno per giorno, uno sviluppatore non deve essere disturbato da un oggetto proxy, che deve essere trasparente per il codice. E la Dottrina che compie perfettamente. Mi ricordo la prima volta che ho dovuto dare un’occhiata a loro è stato quando mi sono imbattuto in un problema con la cache. Non hai bisogno di sapere che cosa gli Oggetti Proxy sono e cosa possono aiutare a realizzare, ma di sicuro aiuta a conoscere. Che cosa parleremo oggi.

Dottrina Oggetti Proxy:

Dottrina Proxy Oggetti sono basati principalmente su due Modelli di Progettazione: Proxy Pattern, e Pigro, il Caricamento del Modello.

Secondo il documentation:

Un oggetto proxy è un oggetto che viene messo in atto o usato invece di “reale” dell’oggetto. Un oggetto proxy può aggiungere comportamento dell’oggetto, essere inoltrata, senza che oggetto di essere a conoscenza di esso. In Dottrina 2, oggetti proxy sono utilizzati per la realizzazione di diverse caratteristiche, ma soprattutto per il trasparente lazy-loading.

Gli oggetti Proxy con loro lazy-loading strutture aiutare a mantenere il sottoinsieme di oggetti che sono già in memoria collegato con il resto degli oggetti. Questa è una proprietà essenziale in quanto senza di essa ci sarebbe sempre stato fragile parziale oggetti ai bordi esterni del vostro oggetto grafico.

Per dirla in termine semplice, un oggetto proxy è semplicemente un oggetto wrapper che estende le funzionalità di base di classe di entità e fornisce il caricamento pigro abilità. Quando si scarica un’entità da un database, l’entità di base è completamente inizializzato, tranne le entità che sono associati con esso. Queste entità sono poi parzialmente caricato e inserito in un oggetto proxy. A questo punto, solo l’id dell’entità associata è noto. Poi, quando abbiamo ulteriormente accedere a un metodo o una proprietà di questo proxy oggetto, Dottrina fare una richiesta al database a carico della proprietà, se non è già caricato.

Come detto prima, questo accade completamente trasparente per l’applicazione a causa del fatto che il proxy si estende la classe di entità. Così, ogni volta che persistono o il filo entità nel Database, non c’è bisogno di preoccuparsi se si dispone di un oggetto proxy o l’effettiva entità. È possibile consultare la Doctrine Documentation per sapere di più sul funzionamento interno di Dottrina e come approccio di ottimizzazione delle query.

Perché gli Oggetti Proxy?

Davvero non c’è molto di oggetti proxy. È semplicemente un oggetto wrapper che si trova sulla parte superiore della base dell’entità e si estende per includere lazy-loading funzionalità. Il vantaggio principale di questo è una funzionalità che permette di ottimizzare le query di database. Quando si sta eseguendo l’big query, o il recupero di una grande quantità di dati dal database, Dottrina passaggi e carica solo i dati necessari al momento, riducendo il tempo di esecuzione. Quindi, quando un’ulteriore proprietà si accede da queste entità, Dottrina caricare dal database se non sono già caricati.

Il problema che rimane è che hai bisogno di sapere quando si sta facendo troppi richiesta di database per caricare le singole proprietà quando ha senso caricare l’intera entità stessa. Naturalmente, questo dipende da come si modella la tua applicazione in modo che si paga per sapere quando a carico di enti attraverso gli oggetti proxy e quando a carico di enti attraverso desideroso di recupero.

Per impostazione predefinita, quando si scarica un’entità dal database, sono completamente inizializzato, ma l’entità associate vengono caricate solo parzialmente. Inoltre, se si conosce l’id dell’entità di base, si può parzialmente carico senza l’inizializzazione di proprietà. Per farlo:

Qui, si sarebbe impostazione di un riferimento all’entità di destinazione.

Per impostazione predefinita, entità associate sono pigro caricato, come detto prima. Tuttavia, se si richiede loro di essere completamente inizializzato, si può semplicemente impostare fetch: EAGER, come mostrato di seguito:

Con fetch: EAGER, invece di essere caricato in modo pigro, entità associate sarà completamente inizializzato.

 

Parziale Oggetti:

Un sacco di persone possono confondere Parziale Oggetti con Oggetti Proxy ed è importante conoscere la differenza tra i due. Un parziale di oggetto è un oggetto di cui non è stato inizializzato completamente dopo essere stato ricostituito dal database e che è staccato dal resto dei suoi dati.

In contrasto con gli oggetti proxy, l’uso di tali oggetti è generalmente sconsigliato. Quando si lavora con un parziale di oggetti, bisogna essere consapevoli di proprietà e metodi che sono al sicuro, accessibile e quelle che non lo sono. Inoltre, i campi che non vengono recuperati dal database non verranno aggiornati con l’EntityManager del UnitOfWork anche se vengono cambiati negli oggetti. Questo è in contrasto con gli oggetti proxy, in cui, anche se si accede a un metodo o una proprietà che non sono inizializzati, sono tranquillamente accessibili in quanto essi saranno caricati dal database a causa del proxy.

Si può imparare di più circa Parziale Oggetti here.