Accessing the same object class in C# / .NET

I have a desktop application made with C# Winforms and an API with .NET, the idea is that many people can access the desktop application and have many unique created classes (forms) but use THE SAME API class (let's call it Manager).

So, if one user updates object A in that Manager class, it should be updated for every other user who accesses that class, without using a database. I guess you have to use the memory in some sort of a way, but I am not sure how.

Another solution I got in my head was when starting the API, to create the Manager class and just pass it as a variable whenever it has to be used, but since it is a C# forms, I am searching for a better solution?

Code - the Manager class:

    private static RoundManager instance;

    public static RoundManager GetInstance()
    {
        if (instance == null)
        {
            RoundHandler _handlers = new RoundHandler();
            instance = new RoundManager(_handlers);
        }

        return instance;
    }

The app

public Ranked(User user1, User user2, Game game, Round round, RoundManager _manager)
{
    InitializeComponent();
    this._manager = RoundManager.GetInstance();
}

What happens is when I run the application on the first machine, the instance is empty so the if statement is true and the Manager is created, however, when I run it on the other machine (after all this, so after the manager class was created), it would do the same thing and read that the instance is null.

It sounds like you are trying to create a model where multiple copies of the desktop application, with each running on a different computer, share some sort of state or ability to call shared APIs. That's a fairly complex problem, and I don't think you'll find a lot of sample code for doing precisely that. I would suggest googling 'distributed cache', 'distributed transaction', 'message queue', and 'event sourcing'.

If all the applications were running on one computer then you could use memory-mapped files as described in another answer, but it sounds like you need cross-computer access to the information with everyone able to access shared services. This is a non-trivial architecture (particularly without a central server) but there are methods of doing it. The architectures are normally used to coordinate servers.

If you possibly can move the API logic into a web service running once on a single persistent machine, this is going to be a lot easier than anything below.

To manage state between desktop applications running on different machines you need to do one of three things:

1. Have one desktop app configured to be a central service that maintains the state and serves API requests from the other desktop apps. i.e. something like a web service running on a server, but inside your app. You need a way of getting all the copies of the application to access it. If the applications are going to run on different networks too, then this service needs to be accessible over the Internet. You also have to consider what happens if this machine is not running at the time that another machine needs it.

2. Cluster of nodes, one of which is elected to be the server at any one time. This solves the issue of a single machine needing to be running at all times, by making all the apps able to be the server and having them decide which one will do this at any particular time. They all then get copies of the state synchronized and can take over if the elected server disappears.

3. Distributed caching - if all the state changes can be sequenced up locally in the desktop app and then sent out to the others periodically, you can make the cluster operation more performant and resilient by implementing a distributed cache that synchronizes the state between all the apps. You then change things locally to the machine the app is running on and let the distributed cache copy the information to the other apps.

To see how (relatively) easily you can do these things, you want to consider:

• Is there shared state that you want all the applications to be able to access and know is completely up to date and consistent at all times?

If yes, then you either need to do (1) or need some way to lock changes and access to information throughout the cluster, change the information in one place and ensure it is replicated before you allow access to it again.

• Can you turn all the operations into a sequence of events?

Let's say you want the desktop apps to call an API that sends all the other desktop apps a message. You can implement this by sending a message from the first app to a central repository of events, and have all the apps check in with the repository every so often. The message is kept in the repository for as long as is needed for all other apps to retrieve it.

Or let's say that you can perform operations in any order on a piece of information and everyone who gets copies of the information can reconcile any sequence of events. A good example is sending money in a distributed banking system.

If all the operations are like those examples, you can implement your use case with distributed caching much more simply than other use cases. It's still tricky to do though.

Another consideration

With any distributed system, you need some way of the machines in the cluster finding each other. Are they all on the same network and can broadcast their presence to each other? Do they need to connect to a central server on the Internet and advise where they can be reached? Do they have the ability to talk directly to each other once they've done that?