ステートフルなアプリケーションに適したORMが必要です。私は、持続的なクライアント接続を持つ低レイテンシのリアルタイムゲームサーバーの要求の間にエンティティを保つつもりです。データベースには1つのサーバーインスタンスしか接続されていないため、「外部」からデータを変更することはできず、サーバーはそのキャッシュに頼ることができます。ステートフルアプリケーション用のORM。 EFは適合していますか？または何か？
ユーザがリモートでサーバにログインすると、そのプロファイル全体がサーバメモリにロードされます。プロファイルデータを操作して機能を提供するために、各ユーザーごとに複数の上位レベルのサービスも作成されます。また、一時的なデータを格納する内部フィールド（状態）を持つこともできます。ユーザーは自分の署名を変更したいとき、対応するサービスにそうするように頼む。このサービスは、ユーザーが自分の署名を変更する頻度を追跡し、10分に1回（たとえば）許可します。このような短い間隔はdbで追跡されません。これは一時的な状態です。この変更は、1つのクエリ：UPDATE users SET signature = ... WHERE user_id = ...を実行しているdbに格納する必要があります。ユーザーがログオフすると、数分または数時間休止した後にサーバーメモリからアンロードされます。ここのDbはストレージだけです。これは私がステートフルと呼ぶものです。
- 一部のエンティティは「静的データ」とみなされ、アプリケーションの開始時に1回だけロードされます。それらは他の「動的」エンティティから参照することができます。 「動的」エンティティの読み込みは、参照された「静的データ」エンティティの再ロードを必要とすべきではありません。
- /
Insert/Deleteは、 "detached"エンティティであっても、変更されたプロパティ/エンティティのみを設定/挿入/削除する必要があります。 - 書き込み操作では、変更を検出するために暫定的にデータベースからデータをロードしないでください（
Selectを実行してください）。 （状態は動的に生成された継承元で追跡できます）。私はローカルに状態を持っていますが、何もロードする意味がありません。 接続スコープの外でも変更を追跡し、必要に応じて「アップロード」を変更したいと考えています。 - 永続オブジェクトの操作参照は変更しないでください。
- DBConnection-per-userは動作しません。予想されるオンラインは数千人のユーザーです。
- "静的データ"からのエンティティは "動的"エンティティプロパティ（外部キーを表す）に割り当てられ、
Updateはそれを正しく処理する必要があります。
ステートレスアプリケーション用に設計されていますが、NHibernateを使用しています。それはセッションへの再接続をサポートしていますが、それは非常に珍しい使用法のように見え、私には文書化されていない動作を使用する必要があり、すべてを解決するものではありません。
私はEntity Frameworkについてよく分かりません。私はそのように使用できますか？または、別のORMを提案できますか？
ユーザがボタンを押すたびにサーバを再作成（または特にリロード）すると、CPUが非常に早く食べられます。 CPUは垂直に高価にスケールされますが、効果はわずかです。逆に、RAMが足りない場合は、横方向のスケーリングと同じようにコードを書くことができます。ここで別のアプローチを使うべきだと思うなら、私はそれについて議論する準備ができています。
Nhibernateがステートレスアプリケーション用に設計された理由がわかりません。 NHのセッションはかなりステートフルなようです。 –
2つのwrt適用アーキテクチャの違いはあまりありません。しかし、この質問は広すぎると意見に基づいている、賞金はそれを修正しません。そして、session.Merge、SaveOrUpdateなどについては、珍しく、文書化されていないものは何ですか？ –
@ GertArnoldこれらのメソッドはSelectを使用します。＃3を参照してください。 Session.Lock（再接続、変更、コミット）をいくつかの文書化されていない振る舞いを持って使用する必要があります（それは2回呼び出すといくつかのチェックを無視できます - 最初のスローのみ）。 – Vlad