Utilisation de MicroORM pour la couche de lecture dans CQRS

cqrs dapper massive

Question

Les gens, je envisage d'utiliser un microORM tel que Dapper.net pour le composant d'accès en lecture d'une application CQRS (Asp.Net MVC), avec Entity Framework étant utilisé pour manipuler le domaine.

Ceci est léger CQRS, je n'utilise pas le sourcing d'événement etc. Je l'ai vu plusieurs fois mentionné que le modèle en lecture seule de CQRS devrait être simple / léger pour interroger la couche de données, en utilisant quelque chose comme ADO.net. Interroger des chaînes dans notre code ou dans un fichier XML. Comment dois-je procéder pour justifier cette approche lorsque nous devons maintenir les mappages de domaine d'un côté et les instructions SQL sur un autre?

Quelqu'un a-t-il utilisé des MicroORM dans une solution CQRS de cette manière? Merci Mick

Réponse acceptée

Oui, vous pouvez absolument utiliser Dapper, PetaPoco, Massive, Simple.Data ou tout autre micro ORM que vous souhaitez. Dans le passé, nous avons utilisé NHibernate pour résoudre le problème, mais il s’agissait d’un poids de 10 000 livres. gorille comparé à ce dont nous avions besoin.

Une chose que nous avons vraiment appréciée avec Simple.Data et Petapoco dans notre évaluation de ces bibliothèques était qu’elles pouvaient adapter leurs requêtes à différents moteurs de bases de données (y compris Mongo) avec un minimum de modifications, tandis que Dapper -Il était "tapé à la chaîne". Ne vous méprenez pas, Dapper est génial et très, très rapide et fonctionnera parfaitement bien. Évaluez simplement vos exigences fonctionnelles et non fonctionnelles avant de vous engager.

Voici le nombre relatif de téléchargements à l'aide de NuGet pour chacun des micro ORM primaires (environ le 1/1/2012). Pour nous, avoir une bonne communauté avec beaucoup de téléchargements est toujours indispensable pour résoudre les problèmes:

  • 5568 Simple.Data
  • 4990 Petapoco
  • 4913 Dapper
  • 2203 Massive
  • 1152 OrmLite

Enfin, une chose que vous voudrez peut-être étudier est votre raisonnement derrière SQL pour vos modèles de lecture. Si votre domaine publie des événements (quel que soit l'origine des événements) et que vous écrivez sur des modèles de vue simples, non-relationnels, vous pouvez vous débrouiller avec des fichiers JSON simples qui sont transmis au navigateur. le navigateur interprète et utilise ensuite pour remplir vos modèles HTML. Il y a toutes sortes d'options disponibles, il vous suffit de déterminer ce qui fonctionne le mieux dans votre scénario.




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