So I’m trying using the ASPNetHeroBoilerplate that was posted the other day for a project that I’ve been kicking around. I’ve never used a CQRS/MediatR/Repository + Onion pattern before, but I decided that this would be a good way to learn it.
However, as I’m starting to change things, I’ve realized that this pattern is making me violate the DRY principal to the point that it might as well not exist.
I’ve had to create my DB model about 6 times for a single entity. And it just feels so wrong. I mean, isn’t the entire point of a model to be the framework that you build off of? Instead I’m barely even touching it other than a few rare points way deep into it.
Is this normal, or am I doing something wrong? Or is perhaps the boilerplate I’m using doing something wrong?
Forgot to include, this is the boilerplate I’m talking about: https://github.com/aspnetcorehero/Boilerplate
I’ve had to create my DB model about 6 times for a single entity.
What are the six different usages of your model? Does the model mean the same thing and serve the same purpose in all these situations?
So there’s several projects that are all part of the solution. The Application, Domain, Infrastructure, then the Presentation.
In the Domain, I have the main entities that are used by EF to generate the database tables.
In the Application layer, there’s several places where these are redefined. For example, there’s Features.<Entity>.Commands and Features.<Entity>.Queries.
In each of the commands, there’s a Create, Delete, and Update namespace. Each of those have a class like “Create<Entity>Command”, that you the need to redefine the model of, then create a “Create<Entity>CommandHandler” class that uses it.
The Delete command only defines the Id, but the Create and Update need all of the properties.
Then the Queries are the same thing. “GetAll<Entity>CachedResponse” which is yet another redefinition of the model class that’s used by the GetAll<Entity>CachedQuery class.
Then in the Presentation layer, you make the models yet again for the page View Model to hold.
It all just seems to incredibly redundant. I might end up trying to strip all of this down, because my idea for my project just does not need 16 layers of abstraction for a single table.
MediatR is a tool, you don’t have to use it for everything. I’ve run into the same issue, the shiny tool works great so you use it everywhere. As much as I love it, I tend to stick with a service object it use mediator from controller to handlers so that there isn’t one giant service class.
What do you mean you’ve had to create it 6 times? Sounds like you are doing something wrong. Can you share some code?
If your justification for putting effort into implementing an architectural pattern is:
“Some guy on the internet said it is a good thing”
I might use it in the future
I need it for a single thing in my otherwise simple domain
Then you haven’t justified it, and it would be a bad idea to use it.
Now if you are fucking around with a pattern to learn it, then it likely will feel pretty pointless. That said, the mediator pattern is rarely useful in the typical line-of-business solutions you will use.
CQRS on the other hand is more about formalising the API model instead of trying to shoehorn a kinda post/patch mechanic with your domain models.