J'essaye d'architecturer une application en utilisant le modèle CQRS au lieu de l'architecture Repositories et Onion au lieu de n couches en utilisant la pile MVC5.Couche de service sur le modèle CQRS
J'ai les couches suivantes en ce moment:
Web.Data - Contains DbContext
Web.Model - POCO classes
Web.Service - Implementation of Commands and Queries using MediatR
--Commands
-----Request
-----Handlers
--Queries
-----Request
-----Handlers
Web.UI
Je pensais à mettre les sur les classes de gestionnaire de logique métier (par exemple Les validations) mais je recon que ces classes ont un accès direct à EF. Est-ce encore un bon endroit pour mettre ces logiques?
Que se passe-t-il si j'ai une logique de livraison ou une logique de livraison? Sur les couches traditionnelles, elles vont naturellement au service d'application, les dépôts étant injectés sur ce service, comment vont-ils s'intégrer dans l'architecture actuelle? Nous ne voulons pas aller dans le référentiel car nous voulons tirer parti de EF dans son ensemble plutôt que de l'abstraire encore plus.
Dois-je avoir un Service Layer traditionnel qui accepte l'interface MediatR et que les Controllers aient l'interface Service à la place?
Ma première question: vos modèles sont-ils de purs sacs de propriétés ou ont-ils _behaviour_? Si ce dernier vous devriez mettre la logique d'affaires dans eux. Bien sûr, si par exemple la validation s'étend sur plusieurs modèles/RA, vous avez besoin d'un service/façade. La validation par sa nature est une sorte de ça dépend, mais vous pourriez jeter un coup d'oeil à ceci [réponse] (http://stackoverflow.com/questions/4776396/validation-how-to-inject-a-model-state- wrapper-with-ninject/4851953 # 4851953) pour de bonnes idées. – kayess
Je suggère que vous obteniez un prenup avant que vous décidiez de votre mariage à Entity Framework. C'est très peu plus que DataSet 2.0 avec une interface de modélisation prête et un tas de choses qui ne devraient vraiment pas être faites à l'intérieur d'une couche d'application. Je vous implore de limiter votre utilisation d'EF à ses générateurs ADO.NET et à l'hydratation dto. Traitez-le comme Linq To Sql sur les vues et les procédures stockées et vous éviterez la douleur. –
@ K.AlanBates n'importe quel cadre ou technique peut causer des problèmes dans les mains des praticiens non qualifiés. EF n'est pas différent. Je pense que les dizaines de milliers de systèmes qui ont été construits en utilisant EF parlent d'eux-mêmes. –