ロジックをリアルタイムの.NETベースのソケットサーバーからRESTfulベースのASP.netWebAPIに移行しようとしています。その理由は、ゲームデザインが変更され、ソケットサーバーでリアルタイムの処理を行う必要がなくなったためです。
移行するには、次のeを実行する必要がありますが、Asp.netの経験がないため、誰かが私を正しい方向に向けてくれることを願っています。
1）ソケットサーバーでは、プレーヤーが接続を確立すると、そのプレーヤーのすべてのデータがデータベースからプレーヤーのインベントリなどのプレーヤークラスのインスタンスに読み込まれます。tcpソケット接続が有効である限り、このPlayerオブジェクトがプレーヤーのデータを保持するメモリ内のキャッシュのように機能するように、サーバー側の接続オブジェクトでこのインスタンスを有効に保ちます。しかし、このPlayerインスタンスをAsp.net Web APIに配置するのに相当する場所がわかりません。これは、セッション状態になりますか？
2）ゲームには、武器がどれだけのダメージを与えるかなど、接続されているすべてのクライアントが利用できる静的データがあります。このデータをデータベースからサーバーのアプリケーションインスタンスのStaticDataオブジェクトにロードします。Asp.net Web APIでアプリケーション全体のデータを保持する場所はどこですか？
3）MVCアーキテクチャを使用していません。現在、クライアントとサーバー間の通信方法は、リクエスト（アイテムの販売など）を行い、サーバーがリクエストを検証して処理し、シリアル化して更新された状態をクライアントに送り返すことです。更新されたデータをobject []配列に入れます。asp.net MVCでは、多くのことが「自動」であり、asp.netで「サーバーに要求を送信->サーバープロセスと更新された状態を送り返す->クライアントが状態を逆シリアル化」するのと同じことになるようです。 Web APIの世界？
1）はい、それをに保存できますSession。
2）と同様にSession、ASPにはがありApplicationます。
3）申し訳ありませんが、質問は少し広すぎて答えられません。MVCパターンは魔法ではなく、コードを作成する必要があります。サーバーにリクエストを送信します。それは、ビュー、つまりプロセス全体の出力を更新するモデルを操作できるコントローラーによって処理されます。このチュートリアルを試して、ASP.netのMVCパターンを理解してください。
最後になりましたが、にデータを保存すると、将来的にいくつかの問題が発生する可能性があることに注意する必要がありますApplication。ユーザーの規模が大きくなるにつれて、複数のIISワーカープロセスを使用してアプリケーションを実行することをお勧めします。これらの各ワーカープロセスには、独自のApplicationオブジェクトがあります。静的データが使用するメモリの量によっては、メモリの問題が発生する可能性があります。代わりに、memcached、redisなどを共有キャッシュとして使用することを検討する必要があります。同じことがセッションデータにも当てはまります。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加