Will Dapper pour la récupération et NHibernate pour CRUD fonctionnent pour une application Web

asp.net-mvc-3 dapper design nhibernate

Question

Je prévois d'utiliser "Dapper" pour la récupération et "NHibernate" pour les opérations CRUD. Est-ce que ce serait une bonne conception de suivre cette approche? L'un des problèmes que j'ai récemment rencontrés concerne les écrans CRUD.

Supposons que j'ai un formulaire de commande de modification. Je récupère l'entité (commande) de Dapper et, tout en la mettant à jour, je dois attacher ces objets à la session NHibernate pour effectuer des opérations CRUD. Ce n'est pas directement ce qui est requis, je veux dire object.delete ().

Quelqu'un pourrait-il fournir des suggestions sur cette conception et existe-t-il une possibilité de l'améliorer? C'est une application web développée en utilisant asp.net mvc 3.


Questions sur la réponse:

  1. Le filtre de session sur l'action signifie-t-il ce que nous utilisons pour l'opération en cours. Si oui, pour l'opération GET, devrait-il être [DapperSession] au lieu de [NHSession]?

    [NHSession] << -------- [DapperSession] RÉSULTAT D'ACTION

    • DapperSession.Get.Entity (1000)
    • Retour vue
  2. J'essaie toujours de comprendre le modèle de PRG que vous avez posté, je posterai si j'ai des doutes.

  3. Puisque tout cela se passe pour l'opération "EDIT", il serait sage de simplement obtenir l'objet avec NHibernate. Cela permet de se débarrasser de tout ce processus avec des coûts peu élevés.

Réponse acceptée

À première vue, cela semble être un choix logique: utilisez Dapper (ou un autre micro ORM) pour GET et NHibernate pour toute méthode d'action POST sur les contrôleurs. Voir pseudo-code): -

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

et pour la méthode post

[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

Comme vous pouvez le constater, ce n’est pas très élégant, car il se peut que vous ayez à appliquer des filtres d’action différents à votre résultat d’action POST. Pour mettre cela en ordre, vous pouvez utiliser le modèle Post Redirect Get (PRG) afin que les contrôleurs GET utilisent Dapper et que les contrôleurs POST aient uniquement accès aux sessions NHSessions.

Voir cette réponse acceptée sur SO pour plus de détails sur la façon de configurer ce modèle.

Maintenant, vos résultats d’action GET et POST ressemblent à ceci: -

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

et pour la méthode post

[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

Cependant, comme vous pouvez le voir, je ne fais que remplacer un attribut de filtre d’action par un autre. MAIS (et c'est un gros mais à mon avis), vous obtenez les avantages d'utiliser le modèle PRG! Pour être honnête, cela ne répond probablement pas directement à notre question, mais c'est une bonne méthode à suivre.




Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow
Est-ce KB légal? Oui, apprenez pourquoi
Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow
Est-ce KB légal? Oui, apprenez pourquoi