Using Akka.NET in a typical MVC application. How?

Question

I have a typical web application using Entity framework to interact with the database. Here is the break down of the app.

1. Demo.Core [contains logging (nlog stuff), helper classes, system wide constants etc]
2. Demo.Entities [contains the Entity framework entities or edmx files only- no contexts]
3. Demo.Business [ contains the data manager, the EF context, business rules using NRules, validation and stuff]
4. Demo.Web [contains the MVC app that is the front end]

Now I want to use Akka.NET in this app. I created an Engine class that encapsulates the Akka System actor and created a logging actor (Demo.Core). I’m thinking of engine as a class that has a send function which can be used system wide and the function than decides which actor is the most suitable to handle the message.

However, I'm unable to decide how to manage the Data context and entity classes in terms of akka.

1. Should I have separate Actor for retrieving each type of entity? or one Actor for retrieving all entities?
2. Should I have multiple actors with different contexts for different roles, for instance DBReaderActor & DBWriterActor or a single actor that has the contextto the database?
3. Is it okay to have an engine that has a single send function as mentioned above or each class should call the appropriate actor itself?
4. Can actors of a system be in multiple assemblies? like Demo.Core & Demo.Business?

5. If I run two instances of Demo.Web one on IIS and one on WebDev would they have 2 separate actor systems or a single actor system (they both use the identical code base)?

   I'm a newbie in Akka.NET so please don't assume things when answering

Answer 1

So the answer to the majority of these questions tends to be "it depends", it depends heavily on your architecture and application requirements but I'll try and break it down here.

1) It depends on how frequently you retrieve entities. Since actors process messages one at a time, if you've got lots of requests per entity then you might end up with long requests to retrieve data if the queue of messages is too long. As Akka.Net is a tool for building concurrent applications, it's usual to split work down into the smallest unit of work, so you can easily distribute the work.

2) It depends on whether your application is constrained by reads or writes and whether you have strong requirements on ordering of reads and writes. Messages are processed serially, so if you have lots of writes going to a database through an actor responsible for both reading and writing, then reads may take some time to be processed. Similarly if you have hard constraints that a certain read must happen before a given write then you'll want the reads and writes to exist in the same queue.

3) Actors are addressed by a URI, so it's possible to retrieve them through a well-known URI and the use of ActorSelection on the ActorSystem instance. There is usually no need to create a custom function to Send to an actor. Instead create common functions to retrieve actor URIs based on the URI parts.

4) Yes actors can exist in multiple assemblies, you just need to ensure they inherit from one of the actor types, typically ReceiveActor or UntypedActor.

5) They'd have 2 separate actor systems but it's possible to join them through either Akka.Remote or Akka.Cluster. Actor systems are usually long running processes though and so are frequently left to run on servers dedicated to running the actor system and front end nodes running the web server, simply join the system and push messages into it or pull data out of it.