¿Cuál es la mejor práctica para configurar la última modificación y quién modificó utilizando NHibernate?

En mi aplicación, tengo una situación en la que necesitamos capturar cuándo se creó y modificó un registro y qué usuario realizó esas acciones. Entonces podría tener un objeto algo como:¿Cuál es la mejor práctica para configurar la última modificación y quién modificó utilizando NHibernate?

public class Product 
{ 
    int Id; 
    int Name; 
    DateTime CreatedOn; 
    int CreatedByUserId; 
    DateTime LastModifiedOn; 
    int LastModifiedByUserId; 
}

¿Cuál es la mejor práctica para manejar estos en NHibernate? ¿Usando un interceptor algo como lo que se describe here?

Fuente

2010-03-05 Mark Boltuc

No creo que haya una "mejor" práctica, pero el uso de oyentes de eventos es más común para esto. Hay un buen ejemplo en http://ayende.com/Blog/archive/2009/04/29/nhibernate-ipreupdateeventlistener-amp-ipreinserteventlistener.aspx

Una cosa que deberá tener en cuenta es que debe almacenar ese ID de usuario en alguna parte. Actualmente estoy haciendo eso asignando una propiedad estática en el oyente al inicio. No es bonito, pero hace el trabajo bien.

Fuente

2010-03-05 15:25:24

De alguna manera, pensé que sería la respuesta :) Supongo que no estaba realmente buscando el "mejor" pero "recomendado" –

Hacemos algo similar, pero pasamos un 'Func ' a nuestro "auditorio". Para las pruebas solo tenemos este retorno de un valor fijo y en producción pasamos una función que llama 'HttpContext.Current.User' –

@Diego Mijelshon Yuck que ES feo ... lamentablemente creo que tendré que hacer lo mismo! – richard

Estoy de acuerdo con Diego en que no creo que haya una mejor práctica. Depende del contexto de tu aplicación. En el enlace de Diego, y para utilizar los oyentes de eventos en el nivel de persistencia (nHibernate), necesita saber cómo buscar al usuario actual. Esto puede no tener sentido según su aplicación. Por ejemplo, si está escribiendo una aplicación ASP.NET MVC, ¿realmente desea que su capa de persistencia dependa de HttpContext para conocer al usuario? Sí, podría pasar algún tipo de estrategia, pero esto no parece que siempre va a ser lo correcto.

Creo que es perfectamente válido que su capa de servicio construya el objeto y agregue el creador. Luego pase el objeto completo, con el creador ya hidratado, hasta nHibernate para persistir. El creador se guardará en la base de datos de la misma manera que cualquier otra propiedad.

Fuente

2010-03-05 16:03:43 manu08

Mi aplicación (ASP.NET MVC) está estructurada usando repositorios, por lo que pasar la información del usuario va a ser interesante. Definitivamente no quiero que los repos tengan una referencia directa a HttpContext, así que voy a tener que encontrar una manera de pasar esa información a los repositorios elegantemente. –

Puede crear una estrategia; crea algún tipo de ICurrentUserProvider y transfiéralo desde la capa de controlador/servicio. ICurrentUserProvier tendrá un delegado apuntando a un método que usa HttpContext para resolver el usuario actual. Dicho esto, esto sigue siendo una violación de DIP y debe evitarse si es posible. – manu08

Uso IoC para inyectar al usuario donde sea necesario, algo como esto en autofac: builder.Register (c => HttpContext.Current.User) .HttpRequestScoped(); – UpTheCreek

¿Cuál es la mejor práctica para configurar la última modificación y quién modificó utilizando NHibernate?

Respuesta

Cuestiones relacionadas