Introduce OrleansAssetOccpuancyProvider

[RayMMond]

Resolve #34

[RayMMond]

@gdlcf88 plz review this 😃

[gdlcf88]

@RayMMond - Pure Orleans Grain usage has better performance. I think there are two better ways:

1. We don't use the repositories(with UOW, AssetOccupancy, and AssetOccupancyCount) but use Orleans's persistence.
2. We still use the repositories but cache the state in the grain for better performance.

[RayMMond]

@RayMMond - Pure Orleans Grain usage has better performance. I think there are two better ways:

1. We don't use the repositories(with UOW, AssetOccupancy, and AssetOccupancyCount) but use Orleans's persistence.
2. We still use the repositories but cache the state in the grain for better performance.

1. I believe we should use the repositories for consistency. What if a user using default implementation of AssetOccupancyProvider decide to use Orleans as provider?
2. With my limited knowledge, the "repositories with state cached" way is hard to keep data synchronized. For example, a silo is crashed and state will be loss since Orleans's onDestroyAsync is not a reliable way to save changed data to database.

@gdlcf88 Any ideas?

[gdlcf88]

1. I believe we should use the repositories for consistency. What if a user using default implementation of AssetOccupancyProvider decide to use Orleans as provider?

I agree that non-breaking migration is more friendly for app developers.

2. With my limited knowledge, the "repositories with state cached" way is hard to keep data synchronized. For example, a silo is crashed and state will be loss since Orleans's onDestroyAsync is not a reliable way to save changed data to database.

You are right. Consistency and high concurrency are difficult to achieve at the same time. See my new design of EShop's InventoryGrain about delay persisting the inventory state, FYI.

[RayMMond]

See #44