Book Image

Distributed .NET with Microsoft Orleans

By : Bhupesh Guptha Muthiyalu, Suneel Kumar Kunani
Book Image

Distributed .NET with Microsoft Orleans

By: Bhupesh Guptha Muthiyalu, Suneel Kumar Kunani

Overview of this book

Building distributed applications in this modern era can be a tedious task as customers expect high availability, high performance, and improved resilience. With the help of this book, you'll discover how you can harness the power of Microsoft Orleans to build impressive distributed applications. Distributed .NET with Microsoft Orleans will demonstrate how to leverage Orleans to build highly scalable distributed applications step by step in the least possible time and with minimum effort. You'll explore some of the key concepts of Microsoft Orleans, including the Orleans programming model, runtime, virtual actors, hosting, and deployment. As you advance, you'll become well-versed with important Orleans assets such as grains, silos, timers, and persistence. Throughout the book, you'll create a distributed application by adding key components to the application as you progress through each chapter and explore them in detail. By the end of this book, you'll have developed the confidence and skills required to build distributed applications using Microsoft Orleans and deploy them in Microsoft Azure.
Table of Contents (17 chapters)
1
Section 1 - Distributed Applications Architecture
4
Section 2 - Working with Microsoft Orleans
10
Section 3 - Building Patterns in Orleans
13
Section 4 - Hosting and Deploying Orleans Applications to Azure

Grains directly interacting with storage

The storage provider plugin model follows the pattern of loading the state at the time of activation. IPersistentState will be injected into the grain through the constructor. The state will be loaded before the OnActivateAsync method. The state will be persisted back to the storage provider by calling WriteStateAsync and can be refreshed at any time by calling the ReadStateAsync method. But this model may not work for all scenarios. In this section, we will see the scenarios that require the grain to access the database directly and ways to achieve that.

Consider the scenario where the write operation demands to call a stored procedure in the Cosmos DB provider, or we need to run a custom query to load the state on an ADO.NET provider. Both these functionalities may not be supported by the existing storage provider. In addition to this, having all that data as part of the grain state and loading it at the time of activation may be overkill...