Will Dapper para recuperación y NHibernate para CRUD trabajan para una aplicación web

asp.net-mvc-3 dapper nhibernate

Pregunta

Estoy planeando utilizar "Dapper" para la recuperación y "NHibernate" para las operaciones CRUD. Entonces, ¿sería un buen diseño seguir este enfoque? Uno de los problemas que enfrenté recientemente es con las pantallas CRUD.

Supongamos que tengo el formulario Editar orden. Estoy recuperando la entidad (orden) de Dapper y mientras la actualizo necesito adjuntar estos objetos a la sesión NHibernate para realizar operaciones CRUD. No es directamente lo que se requiere, quiero decir object.delete ().

¿Podría alguien dar sugerencias sobre este diseño y existe la posibilidad de hacerlo mejor? Es una aplicación web desarrollada usando asp.net mvc 3.


Preguntas sobre la respuesta:

  1. ¿Significa el filtro de sesión en la acción lo que estamos usando para la operación actual? Si es así, para la operación GET, ¿debería ser [DapperSession] en lugar de [NHSession]?

    [NHSession] << -------- [DapperSession] OBTENER RESULTADO DE ACCIÓN

    • DapperSession.Get.Entity (1000)
    • Vista de retorno
  2. Todavía estoy tratando de entender el patrón PRG que has publicado, lo publicaré si tengo alguna duda.

  3. Como todo esto sucede para la operación "EDITAR", sería aconsejable solo obtener el objeto usando NHibernate también. Esto le permite deshacerse de todo este proceso con un costo de poca sobrecarga.

Respuesta aceptada

A primera vista, parece una opción lógica usar Dapper (u otro micro ORM) para GET y NHibernate para cualquier método de acción POST en los controladores. Ver pseudo-código): -

[DapperSession]
GET ACTION RESULT
  - DapperSession.Get.Entity(1000)
  - Return view

y para el método de publicación

[NHSession, DapperSession]
POST ACTION RESULT
  If Model.State is valid
    - entity = NHSession.Get.Entity(1000)
    - update entity
    - redirect to ...
  end if

 - DapperSession.Get.Entity(1000)
 - return view

Como puede ver, esto no es tan elegante, ya que puede tener diferentes filtros de acción para su resultado de acción POST. Para ponerlo en orden, puede utilizar el patrón Obtener redireccionamiento (PRG) para que los controladores GET utilicen Dapper y los controladores POST solo tengan acceso a NHSessions.

Consulte esta respuesta aceptada en SO para obtener detalles sobre cómo configurar este patrón.

Ahora sus resultados de acción GET y POST se verían así: -

[DapperSession, ImportModelStateFromTempData]
GET ACTION RESULT
  - DapperSession.Get.Entity(1000)
  - Return view

y para el método de publicación

[NHSession, ExportModelStateToTempData]
POST ACTION RESULT
  If Model.State is valid
    - entity = NHSession.Get.Entity(1000)
    - update entity
    - redirect to ...
  end if

 - return redirect to GET

Sin embargo, como puedes ver, todo lo que realmente hago es sustituir un atributo de filtro de acción por otro. PERO (y esto es grande, pero en mi opinión) ¡obtienes los beneficios de utilizar el patrón PRG! Para ser honesto, esto probablemente no responde nuestra pregunta directamente, pero es un buen método a seguir.



Licencia bajo: CC-BY-SA with attribution
No afiliado con Stack Overflow
Licencia bajo: CC-BY-SA with attribution
No afiliado con Stack Overflow