Skip to content

Document Microservice vs. Common vs. Unity boundary changes in 2.x and beyond #68

@allister-beamable

Description

@allister-beamable

Between 1.19.23 and 2.x the way that C# code used by both Microservices and Unity client code changed. That is, the distinction between "this code can be accessed and compiled during Unity builds" and "this code only pertains to C#MS builds" got stricter. The practical upshot of this for developers upgrading from Beamable Unity SDK 1.x to 2.x and beyond is that dependencies might no longer be accessible, demanding some refactoring.

The general pattern is:

  • Identify code used by the Unity build that depends on server-only classes
  • Refactor dependent code to enforce separation of concerns
  • This may require adding in-between classes in the Common assembly

One concrete example is using data storage objects (DSOs) as both DSOs and DTOs (data transfer objects): in 1.19.23 it was easier to get away with using one class in both roles. However, in 2.x and beyond the stricter separation means that the client side can no longer rely on dependencies like StorageObject or BsonElement being present. In that case, the solution is to create a separate DTO that is dependency-free but can be mapped/converted to the DSO in C#MS code when storage is needed.

Metadata

Metadata

Assignees

No one assigned

    Labels

    documentationImprovements or additions to documentationenhancementNew feature or request
    No fields configured for Feature.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions