アプリケーションの状態をどこに置くか？

Question

コード内では、オブジェクトの作成（ステートフルオブジェクト）を置くのに最適な場所はどこですか？どの層に？

例えば、私はいったんHibernate DAOクラス内にオブジェクト参照を置いていましたが、DAOクラスは状態を持たないため、これは間違っていると言われました。状態は 'サービス層'内にある必要があります。

私は、UpdateCart（）などの定期的なメソッド呼び出しで新しいオブジェクトを作成すべきではないと言われました。オブジェクトの作成にはコストがかかり、どこにでもあなたのコードに座ってはいけません。それは、初期化型のメソッドにだけ座っている必要があります。たとえば、電子商取引アプリケーションにカートが必要な場合は、セッションに入れます。何らかの一般的な主オブジェクトが必要な場合は、初期化コードに入れます。一度そこに作成し、アプリケーションの残りの部分に後でそのインスタンスにアクセスさせます。すべての呼び出し時にこのインスタンスを作成しないでください。

私はこの全体の設計原則について混乱しています。私が聞いた最も奇妙なことは、アプリは国家を持っているとは考えられていないということです。状態は、データベースが存在するデータレイヤーに保持されます。本当に？私はこれらのデザインコンセプトにはまったく新しいので、もっと教育を受けるためにどこを見るべきかわかりません。 GoF？デザインパターンの本？目標は、定性的なコード（すなわち、ビジネスで使用される）を作成することです。

おかげ

Answer 1

何が良い習慣であることは基本ドンにそれがあるプロジェクトの種類を変えることができます。

ほとんどのプロジェクトでは、オブジェクトを作成するのにCPUのコストがかかりません。必ずしも明確に表現されていないコストは設計コストです。アプリケーションには、すべての状態とオブジェクトを制御された一元的な方法で管理する必要がある設計手法があります。これは、保守性を向上させ、設計を単純化するためによく行われます。私はあなたに非常にはっきりと綴られていない限り、デザインが何であるかを知っているだけではないと思います。

私はチームの残りの部分が特定の方法で作業することに慣れていると思うし、この方法論を文書化したり教えたりする必要がないと思っています。これは生産的なIMHOではありませんが、状態やデータ構造の配置に関しては、あなたが持っている状況に対処して質問する必要があります。

Answer 2

'アプリは状態を持っていないと思われます。状態は、データベースがあるデータレイヤーに保持されるべきです。

「ステートレスアーキテクチャー」と呼ばれる標準的なデザインがあります。すべてのアーキテクチャがステートレスでなければならないかどうかはもちろん疑問であり、まさにその言葉は議論の余地があるかもしれません。

ほとんどの「ステートレス」アプリケーションは、実際には状態を持っていますが、上記の状態（馬小屋なし）のルールとして、この状態は1つのグローバルな場所に保持されます。データベース。 Peterが言及しているように、これは保守性と簡素化の理由がありますが、これはscalabilityのものであるとよく聞かれます。データベース以外には何も表示されない状態でも、フロントエンドサーバーの追加、サーバーの処理、そして何を持っているのかは簡単に考えられます。

これにはいくつかメリットがありますが、一時的な状態と権限のある状態を区別しなければならないと思います。

一時状態は、ご注文手続きの際の場所や既に入力した詳細のようなものです。 Java EEでは、これを例えば次のようにしておくことができます。 @ConversationScoped Bean、または@Stateful Beanです。これは、あなたがウェブレイヤー内に保持している状態です。ビジネス層。

この利点は、使いやすさ、パフォーマンス、および単一の中央データベースのアンロードです。もちろん、中央データベースに一時的な状態を保存することもできますが、これを通常の非一時的なデータから離しておくと、プログラミングの複雑さが増すことがあります。また、通常、Webレイヤーからデータを取得する方がはるかに高速で、データベースからいくらかの負荷を取り除きます。

多くのシステムでは、単一のマスターデータベース（書き込みを受け入れるデータベース）しかないため、この単一のデータベースは、そのセットアップで大きなボトルネックになる可能性があります。

実際のアーキテクチャとセットアップによっては、ではなく、というデータベースで一時的な状態を維持することができます。

一時的な状態が現在保持されている単一のサーバーにクライアントが固執する必要があるという欠点があります。これは典型的には「スティッキセッション」と呼ばれます。このクライアントが対話している1つのサーバーが失敗したり、再起動が必要な場合、クライアントはこの一時的なデータを失います。クラスタ内のすべてのノードまたは近くのノード（バディレプリケーション）に状態を複製するようなスキームがいくつかありますが、これは事態をさらに複雑にし、ネットワークを過負荷にする可能性があります（すべてのノードが常に複製している場合）。

信頼できる状態は、唯一の情報源である共有データを表すことを意味します。この種の状態は、ほぼ常に中央の場所にあるようなものですが、場合によってはそれが、ウェブノード。

たとえば、最近の価格のリストがあり、これを中央の場所に保存するのではなく、入力されたWebノード上に保存します。今、この情報を持つ「唯一の」Webノードという概念があり、他のサーバーはこの「唯一の」Webノードしかないと仮定して始めることができます。追加のノードを追加することは、この前提を壊すので不可能です。