6

コードのどこにオブジェクト作成 (ステートフル オブジェクト) を配置するのが最適で、どこに配置しないのですか? どのレイヤーで？

たとえば、Hibernate DAO クラス内にオブジェクト参照を配置したことがありますが、DAO クラスには状態があると想定されていないため、これは正しくないと言われました。状態は「サービス層」内にある必要があります。

UpdateCart() などの繰り返しのメソッド呼び出しで新しいオブジェクトを作成するべきではないと言われました。オブジェクトの作成にはコストがかかるため、コードのどこにでも置いておくべきではありません。初期化タイプのメソッドのみに配置する必要があります。たとえば、e コマース アプリケーションでカートが必要な場合は、それをセッションに入れます。一般的なメイン オブジェクトが必要な場合は、初期化コードに入れます。そこで一度作成し、アプリケーションの残りの部分が後でそのインスタンスにアクセスできるようにします。呼び出しごとにこのインスタンスを作成しないでください。

この設計原則全体について混乱しています。私が聞いた最も奇妙なことは、「アプリには状態があるはずがない」ということです。状態は、データベースがあるデータ層に保持する必要があります。本当に？私はこれらの設計概念にまったく慣れていないため、より多くの知識を得るためにどこを見ればよいかわかりません。GoF? デザインパターンの本？目標は、定性的なコードを作成することです (つまり、ビジネスで使用するため)。

ありがとう

4

2 に答える 2

2

プロジェクトの種類に応じて、適切なプラクティスは異なります。

ほとんどのプロジェクトでは、オブジェクトの作成は CPU にとってそれほど高価ではありません。必ずしも明確に表現されていないコストは、設計に対するコストです。あなたのアプリケーションには、すべての状態とオブジェクトを制御された集中型の方法で管理する必要がある設計方法論があるようです。これは、保守性を向上させ、設計を簡素化するためによく行われます。非常に明確に説明されていない限り、デザインが何であるかを知っているべきではないと思います。

チームの残りのメンバーは特定の方法で作業することに慣れているのではないかと思います。この方法論を文書化したり、教えたりする必要はないと思います。「間違った」場合は教えてください。これは生産的な私見ではありませんが、状況に対処し、状態またはデータ構造の配置に関して質問する必要があります。

于 2012-09-23T09:14:24.163 に答える
1

'アプリは状態を持つべきではありません。状態は、データベースがあるデータ層に保持する必要があります。

これが標準である設計があり、適切に「ステートレス アーキテクチャ」と呼ばれます。もちろん、すべてのアーキテクチャがステートレスであるべきかどうかは疑問であり、その用語自体もおそらく議論の余地があります。

実際、ほとんどの「ステートレス」アプリケーションには状態がありますが、上記のルールで述べられているように (駄洒落ではありません)、この状態は 1 つのグローバルな場所に保持されます。データベース。Peter が言及しているように、これの理由は保守性と単純化かもしれませんが、これはscalability. データベース以外のどこにも状態が表示されないため、フロントエンド サーバー、処理サーバーなどを簡単に追加できると考えられています。

これには確かにメリットがありますが、一時的な状態と正式な状態を区別する必要があると思います。

一時的な状態とは、注文プロセス中の場所や、既に入力した詳細のようなものです。Java EE では、@ConversationScoped Bean や @Stateful Bean などでこれを保持できます。したがって、これは Web レイヤー resp 内に保持する状態です。ビジネス層。

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

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

実際のアーキテクチャと設定によっては、データベースに一時的な状態を保持しないことで、実際にスケーリング能力が向上する場合があります。

欠点は、一時的な状態が現在保持されている単一のサーバーにクライアントを固定する必要があることです。これは一般的に「スティッキー セッション」と呼ばれます。このクライアントが対話している 1 つのサーバーに障害が発生したり、再起動が必要になったりした場合、クライアントはこの一時データを失います。クラスター内のすべてのノードまたは近くのノードに状態をレプリケートする (バディ レプリケーション) などのスキームがいくつかありますが、これは状況をさらに複雑にし、ネットワークに過負荷をかける可能性があります (すべてのノードが常に相互にレプリケートしている場合)。

権限のある状態とは、唯一の情報源である共有データを表すことを意味します。この種の状態は、ほとんどの場合、中央の場所に配置したいと考えていますが、Web ノードなどに保存されている場合もあります。

たとえば、最近の価格のリストがあり、これを中央の場所に保持する代わりに、入力された Web ノードに保持するとします。現在、この情報を持つ「唯一無二の」Web ノードの概念があり、他のサーバーは、この「唯一無二の」Web ノードしかないと想定し始める可能性があります。この前提が崩れるため、ノードを追加することは現在不可能です。

于 2012-09-23T09:54:29.247 に答える