5

I'm using AKKA.NET to build asynch processing logic in a .NET Core Console application (framework net46).

Up to now I have used the built-in dependency injection to provide access to my IDbConnection object (or ApplicationDbContext for EF). This makes it easy to unittest.

I'm very much in doubt what will be best practice when dealing with database access from within Actors.

An easy approach is to write good old using-blocks like this: 

using(var db = new ApplicationDbContext()) {
   ...query, modify and save objects using the db object
}

and completely ignore the DI-container.

I'm curious to find out, what experienced AKKA-developers consider best practice in this case?

Nikola Schou
  • 2,386
  • 3
  • 23
  • 47
  • Would you not just treat it as any other dependency your actor has? I.e. Still use IDatabaseThing as a constructor parameter? (Not sure if this applies to EF as I've not used it) (I also tend to not use a DI container) – tomliversidge Aug 30 '16 at 14:43
  • Also take a read of item no. 2 in this blog post https://petabridge.com/blog/top-7-akkadotnet-stumbling-blocks - advises against using a DI container which I would agree with – tomliversidge Aug 30 '16 at 17:06
  • The problem is that an actor often will be long-lived whereas a database connection (or EF dbcontext object) should be disposed after using it (and handed back to the underlying connection pool I assume). So the database connection cannot be handed over to the actor during construction. I guess I will have to create a factory delegate or class and pass that object in the constructor. Then everytime I need a concrete connection inside the actor receive method I can request the factory to create a connection object. – Nikola Schou Aug 30 '16 at 20:43
  • Yes that's exactly what I was thinking you'd need to do :) - the actor would be responsible for managing the lifetime of each connection it needs, and IDatabaseThing would allow you to create and destroy these connections. – tomliversidge Aug 31 '16 at 04:26

0 Answers0