Question: why IPersistentState if already EFCore?

[Banyc]

I'm new to this project after learning microservice patterns. Little to no mention of EFCore in neither orleans/samples nor video introduction on YouTube. It makes me wonder if EFCore is not even supported. According to the documentation and my novice perception, IPersistentState resembles EFCore which I have gotten used to.

The question is why we need IPersistentState if EFCore has already existed? It seems like there is a reason for not using EFCore but I'm baffled.

[JorgeCandeias]

TLDR; They're apples and oranges, both solve different problems and over different sets of data. These can overlap or not, it depends on the application. You're free to add EF to your solution and mix and match whichever you prefer in grain code, they work together just fine.

Long read:

• Entity Framework is an ORM that abstracts C# query code from underlying relational databases. Its purpose is to keep C# developers from having to write and manage SQL queries by hand against the application data model.
• The Orleans persistence system abstracts basic C# read-write code from any kind of blob(ish) storage, including relational databases, but not limited to them, and the plugins handle all the platform specific access code for you. Its purpose is to persist a grain's internal memory state with minimal effort and code (not even custom query code like EF) in order to support the grain lifecycle. Persisting a grain's internal memory state is what makes a grain "immortal" and able to jump between silos like nothing happened. If the existing plugins aren't enough, developers can implement their own persistence provider against any persistence store of their choosing, relational or not. You can even persist against raw files if you wish.

An underlying key note above is that grain internal state may or may not overlap with the application data model, both in structure and content.

Both systems have benefits and drawbacks. With the Orleans persistence system, you can move between Azure Storage to SQL Server to Dynamo DB without changing a single line of C# business code, by design. This is less straightforward with EF as it is not designed to abstract blob storage in the first place (you can do it, but in the context of a relational model), and even with relational databases, there's always some kind of change you must do on your model definition, to address differences between RDBMS flavors. You're also adding more complexity to user code with EF than you are with the Orleans persistence system.

On the other hand, it can be from a nuisance to impossible to run custom reporting queries directly from blob storage as compared to a relational database, especially if your data is stored in some efficient binary format. So if you're persisting data that must be reported on from storage itself, then a relational model may be the way to go, or perhaps some document store like CosmosDB, or at the very least some distributed table structure like Azure Table Storage. Same thing for persisting large collections of objects, even if you don't need to report on them, blobs aren't very good for this. The Orleans persistence system has plugins for readable storage like Azure Table Storage to reduce the impact of this problem.

As a rule of thumb when prototyping an Orleans application, you'll tend start with the built-in persistence model for simple things, configured against your backend of choice, and then move to a full repository model as conditions justify it, and as you clarify the difference between the grain state and the relational/document/blob data model.

[SebastianStehle]

Great answer, I would add this to the docs, because it has been asked a lot in the last time.

[Banyc]

@JorgeCandeias Thanks you for the in-depth explanation of the purpose behind the design and the analysis of possible difficulties and solutions in microservice architectures!