Answer the question
In order to leave comments, you need to log in
How to transfer data from the database to the UI?
I have a db layer (current game session data) that implements the IGameManager interface.
There is also a UI layer represented by IUIManager, which wants to be updated immediately after the information in the database is updated. The task is to make the architecture scalable and not be tied to specific implementations.
I do not understand how to implement communication between these two layers and I will be glad to hear your advice.
What I tried and what conclusions I came to:
1) If you solve the problem head-on (for each field in which IUIManager is interested in making events inside IGameManager'a), you get a very bloated IGameManager interface.
2) It makes no sense to make an intermediary between the two layers, because we will either be forced to switch to specific implementations, or we will return to problem 1
The idea of communication using messages is ripening in my head (when data is changed in a particular GameManager, it sends a message to IUIManager, in which it indicates which specific data was changed and to which). The IUIManager in turn "offers" this message to everyone, let's say IUIMember. IUIMember, in turn, decides whether he is interested in the message or not. I need to clarify that I understand that there will be an overhead due to the fact that the IUIManager will be forced to "offer" EVERY data change message to EVERY IUIMember, and this scares me.
Does it make sense to bother like this, or is it done differently? I would be very glad to any source that will help to gain knowledge in design.
Answer the question
In order to leave comments, you need to log in
There is a flux architecture that solves this issue. It is for the web, but I have seen many articles and solutions about its use in the unit, I advise you to take a look, this is probably what you are looking for, only there probably with webapi (ajax, rest, comet), in your case it will be db, if the word component is used there, then this is probably called a widget in the unit.
generate events (event) through delegates (Delegate). as detailed as possible, every single significant change is a single event. who needs to track what events - he signs. processing queue, mutexes / semaphores if necessary in critical sections.
upd: generate in the DB layer, right when processing query results.
upd2: Damn, I didn’t understand at first, this method doesn’t suit you for some reason. I don't know others. I will follow the thread.
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question