2011-04-21 7 views
6

He estado intentando implementar este patrón en un nuevo proyecto como lo describe udi dahan.utilizando el patrón de evento de dominio

Me gusta la idea de si pero aún no estoy seguro de en qué casos se debe solicitar (nuevo en esto ...).

Por ejemplo, digamos que tengo un evento OnUserCreated. Quiero que uno de los controladores envíe un correo electrónico de confirmación al usuario. Pero, ¿qué sucede si el evento se dispara? El correo electrónico se envía y luego se comete un error al comprometer la transacción y los datos nunca se guardan en la base de datos. ¿Es el patrón aplicable en esta situación? He leído que la gente dice que no, pero algunos proyectos que he estudiado lo hacen de hecho. ¿O es esto algo que solo debería utilizar para cargar y actualizar otras entidades ... por otro lado, leí a alguien decir que las entidades asociadas necesarias para la operación ya deberían estar cargadas, por lo que no debería cargarlas desde la base de datos en una evento.

Respuesta

7

Por supuesto, depende de cómo elija implementar su sistema.

Se puede considerar varias opciones aquí:

1.-dos fases Cuando se realiza una confirmación en dos fases, básicamente, cada manejador contiene 3 métodos: uno para preparar, uno para cometer y uno para rodar Espalda.

Para todos los controladores de eventos, primero se llama a Preparar. Si ninguno de estos informa un problema, se invocan todos los métodos Commit() de los manejadores. Si alguno de ellos informa un problema, a pesar de que no se informaron problemas por las llamadas Prepare(), entonces para todos los controladores cuyo Commit() ya se haya ejecutado, usted llama a sus métodos Rollback().

2. Controladores de eventos internos y externos Otra opción es separar los controladores de eventos. Puede publicar un evento, como UserCreated, que es procesado por los controladores de eventos que participan en la transacción primero. El evento se almacena en el DB como parte de la transacción. Luego puede tener manejadores de eventos externos que solo reaccionen a eventos que ya están almacenados en la base de datos, como su remitente de correo electrónico. Solo se pueden llamar después de que se haya comprometido la transacción inicial.

Estoy seguro de que puede pensar en más formas de manejar su situación específica.

3

El uso de eventos de dominio le permite mover algunas acciones (envío de correo electrónico) fuera de la transacción comercial (crear el usuario). La publicación de los eventos se enlista en la misma transacción que su transacción db, por lo que si la transacción db falla, los eventos no se publicarán. El uso de un sistema de cola de mensajes duradero (msmq) garantiza que si el evento se publicó, el controlador finalmente se ejecutará.

Su flujo debe ser algo como esto:

Begin Transaction 
    Receive Command 
    Call Aggregate Method 
     Publish Events // will only be published if the transaction succedes 
Commit Transaction 

Begin Transaction 
    Receive Event 
    Send Email 
End Transaction 

Como nota al margen de un intento para nombrar sus eventos sin el prefijo "on", ya que es más fácil de usar en oraciones.

Cuestiones relacionadas