游戏逻辑应该在 android 中的模型-视图 ViewModel 模式中的哪里
我目前正在使用模型-视图 ViewModel 模式开发一个 Android 扑克游戏应用程序，我不确定游戏逻辑的正确位置应该在哪里。目前的架构看起来是这样的：
GameActivity --> GameViewModel --> Repository --> Database
| ^
| :
| :
|-> PokerGame
GameViewModel 调用 PokerGame 方法来初始化游戏并传递玩家的交互。 PokerGame 由 GameViewModel 观察。 PokerGame 有一个内部线程，它会一直运行到游戏结束，并频繁地将数据传递到 GameViewModel，就像当前的 jetons 分布一样。
我正在使用 Room 和 LiveData，因此当数据库发生更改时，GameActivity 始终会触发。
如果存储库保存 PokerGame，更好的方法是什么？
I'm currently developing a poker game app for android using the Model-View ViewModel pattern and I'm not sure where the correct place for the game logic should be. The architecture looks currently something like this:
GameActivity --> GameViewModel --> Repository --> Database
| ^
| :
| :
|-> PokerGame
The GameViewModel calls PokerGame Methods for initialising the game and passing interactions by the player.
The PokerGame is observed by the GameViewModel. The PokerGame has an internal Thread which runs until the game is over and frequently passes data to the GameViewModel, like the current distribution of jetons.
Im working with Room and LiveData, so the GameActivity always triggers when changes are made to the database.
What would be a better approach, should the Repository hold the PokerGame instead?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在简单的 MVVM 模式中，您获得了表示层（视图和视图模型）和数据层（存储库和数据源，例如您案例中的数据库）。
游戏逻辑在某种程度上是一种业务或领域逻辑。现在演示文稿只是向用户呈现或显示信息。 ViewModel 应该尽可能愚蠢。它们仅显示模型的具体数据。另一方面，数据也不应该了解任何更高的逻辑。
正如马克所说，存储库可以被视为域逻辑。因此，在您的情况下，正确的位置是存储库。
存储库（通常）被视为数据层的一部分，用于仅获取数据（从本地数据库或远程网络）。这就是为什么我使用带有用例的领域层。
用例有一个用例，可以连接到多个存储库来完成多项任务，例如设置新游戏、保存游戏状态、加载游戏、操作游戏、结束游戏回合等。事实上，我的用例通常非常薄，因此我的用例有一个游戏引擎的实例，并且引擎可以根据需要连接到任何存储库。
In a simple MVVM pattern you got the presentation layer (view and viewmodel) and the data layer (the repository and datasources, e.g. database in your case).
A game logic is somehow a business or domain logic. Now the presentation is just presenting or showing informations to a user. ViewModels should be as dumb as possible. They only show concrete data of the model. On the otherside data should not know about any higher logic either.
As Mark stated the repository can be seen as domain logic. So in your case the correct place would be the repository.
The repository is (often) seen as part of the data layer to just fetch data (from local database or remote network). That is why i use a domain layer with UseCases.
UseCases have one single usecase and can connect to several repositories to fullfill several task, like setting up a new game, saving a game's state, loading a game, manipulate the game, ending a game's turn and so on. In fact my use cases are often very thin, so that my usecases have an instance of the game engine and the engine connects to any repository if needed.