Perché il modello Unità di lavoro è considerato veloce ed efficiente quando si lavora con un ORM?

Question

Perché il modello Unità di lavoro è considerato veloce ed efficiente quando si lavora con un ORM?

#1 da (5 voti)
#2 da (-1 voti)

1

Lavorando con Doctrine 2 mi sono imbattuto nel seguente paragrafo.

In fact, since Doctrine is aware of all your managed entities, when you call theflush() method, it calculates an overall changeset and executes the most efficient query/queries possible. For example, if you persist a total of 100 Product objects and then subsequently call flush(), Doctrine will create a single prepared statement and re-use it for each insert. This pattern is called Unit of Work, and it's used because it's fast and efficient

Non sono al passo con i database relazionali e la ORM teoria quindi mi chiedevo perché è Modello Unità di lavoro considerato veloce ed efficiente?

rdbms unit-of-work

posta Peter Kelly 16.12.2011 - 12:08

fonte

2 risposte

Leggi altre domande sui tag rdbms unit-of-work

Devo decomprimere le cerniere prima di archiviare? Che cos'è il pattern "Trova-Fix-Verifica"? [chiuso]

score 5 · Answer 1

Una ragione per cui il modello di unità di lavoro può essere efficiente, come afferma il paragrafo, è perché può sequenziare diverse operazioni e riutilizzare le risorse.

L'uso dell'unità di lavoro fornisce un contesto che può contenere diverse operazioni in una singola transazione che potrebbe essere altrimenti difficile da gestire insieme.

Inoltre, non solo l'unità di lavoro utilizza una singola istruzione preparata per l'efficienza, ma può anche essere in grado di inviare molti inserti o aggiornamenti al database in una singola chiamata, se il driver del database lo supporta, anziché eseguire ogni inserto o aggiornamento individualmente.

score -1 · Answer 2

Penso che si usi l'unità del modello di lavoro con gli ORM perché è un modello che è facile da tradurre dal codice alle transazioni del database poiché entrambi hanno gli stessi limiti logici. Puoi testare la tua unità di lavoro senza un database.

La velocità e l'efficienza sono davvero dei dettagli di implementazione.