A while ago I wrote about creating Actor System and top-level actors. Sadly it was stored in a static field. And keyword static is … let’s say it’s not one of my favourites. Today I’ll show you how I’m doing the exact same thing but in Dependency Injection container.

As I’ve mentioned in previous posts about Akka.NET, everything that actor knows is stored in memory. While we can skip any database or IO related bottlenecks because things in memory are generally speaking very fast, we must remember that memory is not a place where you can store your data for an extended period of time and keep it. So let’s talk about persisting it.

Let’s take a closer look at our actors, how their life looks like, what exactly they’ve been doing and what they can do. As they are basic building block of applications built on actor model it’s crucial to understand and being able to communicate with them.

Actor model concept fascinated me since I’ve heard about it for the first time. It’s been on my todo list ever since and Get Noticed 2017 is great opportunity to give it a try. That’s why there is an actor responsible for almost anything in Me2.0. But, what is an actor, actor model and are benefits of using it in our projects? You’ll find out in a minute.

W poprzednim wpisie pokazałem, w jaki sposób możemy zaprojektować obsługę błędów. Jak widać mamy do dyspozycji sporo opcji. Z punktu widzenia AKKA.NET nie jest to jednak tak skomplikowane. Wystarczy przeładować jedną metodę i zwrócić odpowiedni obiekt. Tak jak w poprzednim wpisie będziemy testować kod na następującym “systemie”: Dla przypomnienia nasz ApplicationUserActor wygląda następująco: public class ApplicationUserActor : UntypedActo...