modular-monolith-with-ddd
modular-monolith-with-ddd copied to clipboard
kgrzybek
Migrate to Autofac 5
Hi @kgrzybek ,
first of all thanks for this project. I've learned a lot from it.
As @kacey90 pointed out (https://github.com/kgrzybek/modular-monolith-with-ddd/issues/69#issuecomment-636439216) autofac 5 introduced some breaking changes and a result is that the current implementation/registration of the generic decorators does not work. So I did some try-and-error and finally came up with a possible solution.
I don't know exactly what the problem is but I think that autofac resolves the command handlers now as IRequestHandler<T, TResult> and then don't recognize the decorators as matching decorators because they're registered for ICommandHandler<T, TResult> (or at least something in that direction).
So what does this change do?
The decorators now implement IRequestHandler<T, TResult> instead of ICommandHandler<T, TResult> and ICommand specifies the generic interface ICommand<TResult> with TResult = MediatR.Unit (this is exactly what IRequest does with IRequest<TResult>). Then the decorators are registered for IRequestHandler<,> and specify that they only get called when the resolved implementing type is a closed type of ICommandHandler<, > or ICommandHandler<>. Another result is that the decorators for the commands without result are now gone because every command is now a command with result, even if its result is Unit.
PS: This project has been my entry for ASP.NET Core, DDD, ... I have'nt had any contact with it before so thanks again. My unterstanding of how things work is now much better. (And please be kind, this is my first contribution to an open source project 😄 😉)
Hi @stone9988 !
First of all, thanks for contribution!
I have to say that I am not sure if we should do that :) In other words, this is the solution of problem which does not exist with the previous version of Autofac. The new version of Autofac introduces this bug and does not provide anything in return (in context of this project, but correct me if I am wrong) :)
What I like in your solution is that each Command has a return type and this is what I thought about before, because I don't like these duplicated decorators.
What I dislike is that decorators implement IRequestHandler<T, TResult> so you don't know whether it is decorating command, query, both or even another type which implements directly IRequestHandler<T, TResult>.
I am not saying not for this PR now, but I need to think more about this change
No, you're right. In context of this project neither Autofac nor Autofac.Extensions.DependencyInjection provide any new features that could be used. Your solution works just fine.
I now that this solution isn't optimal and that it has its advantages and drawbacks.
So I'll leave it up to you what you want to do with this PR. I just wanted to show a way (not saying it's the only one) how to work with Autofac 5 at the moment because others already had this kind of issue (like in #68 and #69 ). So you can leave it open, close it, think about it, I'm fine with your decision and if I find a better solution I'll just notify you again.
And maybe this bug/feature/behavior (whatever it is) in Autofac will get fixed in a future version and makes this whole change unnecessary. If that is the case, I'll notify you (depending on you for how long you plan to maintain this project).