3

I'm trying to architect an application using CQRS pattern instead of Repositories and Onion architecture instead of n-layers using MVC5 stack.

I have the following layers right now:

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

I was thinking to put the Business Logic (e.g validations) on the Handler classes but I recon that those classes have direct access to EF. Is it still a good place to put those logic?

How about if I have an Emailing logic or shipping logic? On traditional layers, they naturally go to Application service having the repositories being injected on that service, how do they'll fit in on the current architecture? We don't wanna go repository route since we want to leverage EF as a whole instead abstracting it even more.

Should I have a traditional Service Layer that accepts the MediatR interface and have the Controllers have the Service interface instead?

Dave Schweisguth
  • 36,475
  • 10
  • 98
  • 121
gnaungayan
  • 522
  • 1
  • 9
  • 22
  • My first question: are your Models just pure property bags or do they have _behaviour_? If the latter you should put business logic in them. Of course if for instance the validation spans across multiple models/AR's you need a service/facade. Validation by it's nature is a kind of it-depends, but you could take a look at this [answer](http://stackoverflow.com/questions/4776396/validation-how-to-inject-a-model-state-wrapper-with-ninject/4851953#4851953) for good ideas. – kayess Feb 09 '16 at 15:24
  • I suggest you get a prenup before you decide on your marriage to Entity Framework. It is very little more than DataSet 2.0 with a prettified modeling interface and a bunch of stuff that really shouldn't be done inside an application layer. I implore you to limit your usage of EF to its ADO.NET generators and dto hydration. Treat it like Linq To Sql over views and stored procedures and you will avoid pain. – K. Alan Bates Feb 09 '16 at 16:30
  • @K.AlanBates any framework or technique can cause problems in the hands of unskilled practitioners. EF is no different. I think the tens of thousands of successful systems that have been built using EF kind of speak for themselves. – Phil Sandler Feb 09 '16 at 16:39
  • 1
    @PhilSandler that first statement goes without saying and isn't really what I'm speaking to. Your "successful" statement is unqualified. Successful build? Successful domain goals? Successful to some kpi? I say (and have consistently stated) that Entity Framework is a valuable technology within the context of a build team to reduce build costs, but it is indistinguishable from magic(Clarke's 3rd law) once you hand the system over to a maintenance team. There is a critical amount of magic that any system can support and I try to reserve magic for more important things than saving some typing. – K. Alan Bates Feb 09 '16 at 16:51
  • @K.AlanBates This is not the place to debate the pros and cons of Entity Framework or ORMs in general. Consider writing a blog post or posting on a discussion group. (It's really my mistake for responding to your original comment.) – Phil Sandler Feb 09 '16 at 17:00
  • 1
    @PhilSandler sure it is (the place to discuss these) The OP mentioned that he wants to stray outside the confines of what EF does well but says he is using Entity Framework. To me, that is a perfect time to mention "Using EntityFramework = Gonna Have a Bad Time" It's like french frying when you're supposed to pizza – K. Alan Bates Feb 09 '16 at 17:01
  • @kayess Right now its just pure properties but later on of course it will have some methods. So if I'll create a service what should I call them? App Service? Thinking what I have right now is the App Service already and how about Mailing Service or Shipping Service where these guys should sit? – gnaungayan Feb 09 '16 at 22:22
  • @K. Alan Bates totally understood your point but we already have done that route on other projects and we really dont like the way how we utilize EF. – gnaungayan Feb 09 '16 at 22:25
  • I'm a little confused by you textually illustrated layering... which doesn't match to the Onion architecture I've studied and used. The way I'd do it is to have your models (that are are property bags) at the centre of your onion, then work outwards to events and commands, then out to handlers... all just semantics. Also are you using an event store... if so, then when your handler/aggregate (assuming they are one in the same) would have all the state it needs at the time it is loaded so no direct DB access is necessary. If not, what are you using for your atomicity/consistency/isolation etc? – cdmdotnet Feb 18 '16 at 01:04
  • There is an illustrated example of CQRS applied as an onion architecture https://github.com/Chinchilla-Software-Com/CQRS/wiki/CQRS-Architecture – cdmdotnet Apr 17 '16 at 10:04

1 Answers1

3

The handler classes should process command and contains logic to orchestrate the completion of task. This logic can include delegation to the domain model, persistence and retrieval, and calling out other services (such as shipping, or emailing). Note, the command handler is just another flavor of an application service. Thus, it should not have direct access to EF and not a place to put the business logic validations.

alltej
  • 6,787
  • 10
  • 46
  • 87