The downside of this solution is that it is quite cumbersome, especially if you decide to delegate database operations to actors which reside at the bottom of your actor hierarchy.

How does the extension deal with this issue?
If ask for the DataContext in a parent, do something and then need do some additional work in the children, how do they obtain the scoped instance of the DataContext without it being passed down?

Thanks for this, I found it incredibly useful for reducing the clutter in my actors and have used it as a mechanism to get a SqlConnection when I need one. Context.GetSqlConnection() is much, much nicer than injecting dependencies. I'm a big fan of DI, but this seems more of a natural fit in the Akka world. Thanks!

I am learning Akka.Net at the moment and the bootcamp in unit 3 / lesson 4 it says to avoid using async / await in favour of PipeTo. https://github.com/petabrid.... Will it be a problem here?

Hi,
It shouldn't be a problem. But you have to be aware that using async/await may result in some overhead.

I see. They initially say "Most developers would default to using await, which has achieved demigod status since its release in 2012. And they would be making the wrong choice." but go on to mention later, that "native support for async and await is now available inside ReceiveActors" since v1.0. So you are right, this is probably okay now. Cheers.

Can you elaborate on why the extension is preferable to dependency injection?

Hi Hauke Lasinger,
That’s a great question. I like to utilize Akka Extensions this way, because it helps me address one of the most common mistakes that one can make while dealing with Akka: Over-dependence on Dependency Injection frameworks. There is a great article dealing with this topic https://petabridge.com/blog... but the whole point boils down to the fact, that actors should manage their own dependencies. If you do DI that way I did in this article, your actors have full control over the lifecycle of dependencies they need (in this case it is DbContext).

Of course, the whole thing with using Akka Extensions is just a syntactic sugar. If you don’t like it, you can just provide IServiceScopeFactory in some other way, and resolve your dependencies from it directly. For me, using Akka Extensions is just the cleanest way of doing it.