Je me souviens encore du bon vieux temps des référentiels. Mais les référentiels devenaient laids avec le temps. Ensuite, le CQRS s'est généralisé. Ils étaient gentils, ils étaient une bouffée d'air frais. Mais récemment, je me suis demandé à maintes reprises pourquoi je ne maintiens pas la logique dans la méthode Action d'un contrôleur (en particulier dans Web Api où l'action est une sorte de gestionnaire de commandes / requêtes en soi).
Auparavant, j'avais une réponse claire à cela: je le fais pour les tests, car il est difficile de tester Controller avec tous ces singletons immuables et la laideur globale de l'infrastructure ASP.NET. Mais les temps ont changé et les classes d'infrastructure ASP.NET sont beaucoup plus conviviales pour les tests unitaires de nos jours (en particulier dans ASP.NET Core).
Voici un appel WebApi typique: la commande est ajoutée et les clients SignalR en sont informés:
public void AddClient(string clientName)
{
using (var dataContext = new DataContext())
{
var client = new Client() { Name = clientName };
dataContext.Clients.Add(client);
dataContext.SaveChanges();
GlobalHost.ConnectionManager.GetHubContext<ClientsHub>().ClientWasAdded(client);
}
}
Je peux facilement le tester / me moquer. De plus, grâce à OWIN, je peux configurer des serveurs WebApi et SignalR locaux et faire un test d'intégration (et assez rapide d'ailleurs).
Récemment, j'ai ressenti de moins en moins de motivation pour créer des gestionnaires de commandes / requêtes encombrants et j'ai tendance à conserver le code dans les actions Web Api. Je ne fais une exception que si la logique est répétée ou si c'est vraiment compliqué et je veux l'isoler. Mais je ne sais pas si je fais la bonne chose ici.
Quelle est l'approche la plus raisonnable pour gérer la logique dans une application ASP.NET moderne typique? Quand est-il raisonnable de déplacer votre code vers des gestionnaires de commandes et de requêtes? Y a-t-il de meilleurs modèles?
Mise à jour. J'ai trouvé cet article sur l'approche DDD-lite. Il semble donc que mon approche consistant à déplacer des parties compliquées de code vers des gestionnaires de commandes / requêtes puisse s'appeler CQRS-lite.
Réponses:
Le CQRS est-il un modèle relativement compliqué et coûteux? Oui.
Est-ce une ingénierie excessive? Absolument pas.
Dans l' article d'origine où Martin Fowler parle du CQRS, vous pouvez voir de nombreux avertissements concernant la non-utilisation du CQRS là où il ne s'applique pas:
Je souligne ci-dessus.
Si votre application utilise CQRS pour tout, ce n'est pas CQRS qui est sur-conçu, c'est votre application. Il s'agit d'un excellent modèle pour résoudre certains problèmes spécifiques, en particulier les applications hautes performances / volume élevé où la simultanéité en écriture peut être une préoccupation majeure.
Et ce n'est peut-être pas la totalité de l'application, mais seulement une petite partie.
Un exemple vivant de mon travail, nous utilisons CQRS dans le système de saisie des commandes, où nous ne pouvons perdre aucune commande, et nous avons des pics où des milliers de commandes proviennent en même temps de différentes sources, à certaines heures spécifiques. CQRS nous a aidés à maintenir le système en vie et réactif, tout en nous permettant de bien dimensionner les systèmes backend pour traiter ces commandes plus rapidement en cas de besoin (plus de serveurs backend) et plus lentement / moins cher lorsqu'ils ne sont pas nécessaires.
CQRS est parfait pour le problème où plusieurs acteurs collaborent dans le même ensemble de données ou écrivent sur la même ressource.
En dehors de cela, la propagation d'un motif conçu pour résoudre un seul problème à tous vos problèmes ne fera que créer plus de problèmes pour vous.
Quelques autres liens utiles:
http://udidahan.com/2011/04/22/when-to-avoid-cqrs/
http://codebetter.com/gregyoung/2012/09/09/cqrs-is-not-an-architecture-2/
la source
CQRS n'est pas un remplacement un pour un pour les référentiels, exactement parce que c'est un modèle complexe et coûteux qui n'est utile que dans certains cas.
Voici ce que Udi Dahan a à dire au mérite:
( source )
Martin Fowler:
( source )
Enfin, Greg Young:
( source )
la source