design patterns - ¿UnitOfWork es igual a Transaction? ¿O es más que eso?

design-patterns data-access-layer

Question

Internet está lleno de información sobre el patrón UnitOfWork ; incluso SO no es una excepción.

Todavía no entiendo algo al respecto. Según tengo entendido UnitOfWork = Transaction in DB . Eso es todo; nada más y nada menos.

¿Es esto correcto?

Mi confusión se debe a cómo se implementa en diferentes ORM . NHibernate usa ISession para algo más que una Transaction . Dapper deja todo a ti.

Mi pregunta aquí es sobre el patrón de diseño solo sin considerar ningún ORM o tecnología.

Si se trata de algo más que una Transaction , explique cómo.

Editar 1

Referencia a this enlace según lo sugerido en respuesta por @David Osborne.

Una unidad de trabajo realiza un seguimiento de todo lo que hace durante una transacción comercial que puede afectar la base de datos. Cuando haya terminado, descubrirá todo lo que debe hacerse para alterar la base de datos como resultado de su trabajo.

Esto significa que UnitOfWork es DBTransaction y más .

Las siguientes son sus responsabilidades adicionales: -

• Mantenga el estado de lo que ha cambiado, insertado, eliminado en esta sesión de trabajo.

• En función de este estado, modifique la base de datos cuando haya terminado el trabajo.

Aunque no se menciona claramente en la cita anterior, también puede controlar el procesamiento por lotes de consultas.

¿Es correcto mi entendimiento ahora?

Answer 1

Se this , AFAIK, de la necesidad de herramientas ORM para rastrear el estado [persistencia] de los objetos durante una transacción lógica / comercial.

Cómo una unidad de trabajo maneja esto, y su relación con la tecnología de almacenamiento subyacente y los objetos almacenados, es un detalle de implementación.

Podría decirse que una transacción de base de datos con una serie de sentencias SQL entre ellas es también una unidad de trabajo. Sin embargo, supongo que la diferencia clave es que la unidad de trabajo, como se define en el patrón, ha abstraído ese nivel de detalle a un nivel de objeto.

Answer 2

Un UnitOfWork es una transacción comercial. No necesariamente es una transacción técnica (transacción db) pero a menudo está vinculada a transacciones técnicas.

En los this se define como

Mantiene una lista de objetos afectados por una transacción comercial y coordina la redacción de los cambios y la resolución de problemas de concurrencia.

No define cómo se escriben los cambios ni el tipo de almacenamiento.

Una aplicación puede escribir cambios en un

• base de datos usando SQL
• sistema de archivos usando streams
• servicio de persistencia utilizando solicitudes http
• caché distribuida o incluso almacenamiento en memoria utilizando invocaciones de métodos

Una UnitOfWork (transacción comercial) recopila cambios en los objetos comerciales y garantiza que otras transacciones comerciales solo verán objetos comerciales válidos.

Por ejemplo, cuando su aplicación ejecuta un caso de uso, modifica los objetos comerciales. Si dos transacciones comerciales (generalmente casos de uso) se ejecutan en paralelo, su aplicación debe ocuparse de los cambios que realiza cada transacción comercial y el momento en que las verán otras transacciones comerciales.

Técnicamente, esto a menudo se hace usando una transacción db. Por lo tanto, una unidad de trabajo suele ser una transacción db.

Las aplicaciones que usan marcos ORM para manejar la persistencia generalmente tienen una relación uno a uno entre la unidad de palabra y la transacción db. Por lo tanto, la diferencia entre una unidad de trabajo y una transacción db generalmente no es relevante para los desarrolladores.