ウェブアーキテクチャ:MVC、遅延初期化、データ転送オブジェクト、ビューでセッションを開く、コンセンサスアプローチはありますか?

StackOverflow https://stackoverflow.com/questions/1969278

質問

典型的な Web 3 層アプリケーションの次の設計 (および理想的なアーキテクチャの提案) にはどのような欠陥があると思いますか?

私の現在のブループリントアプローチは非常に大まかにこれです（Java、Spring、Hibernate、JSPを想定）

コントローラ

ステートレス。(遅延初期化例外を避けるため) 読み取り専用トランザクションでラップされる可能性があり、サービスのみを介して永続ストレージからエンティティを取得し、それらをモデルとしてビューに渡します。それら上でビジネス ロジックを実行し (BL はサービス層のみにある必要がありますか?)、必要に応じて永続化のためにサービス層に戻します。

長所:読み取り専用トランザクション ラッピングの場合 - 接続は 1 つだけで、同じ永続エンティティに対する冗長ヒットはなく、クエリ キャッシュをより適切に利用し、サービス層はリクエスト パラメーターや必要な初期化グラフ スパンを「認識」すべきではなく、遅延初期化例外を回避します。

短所:読み取り専用トランザクションのアプローチにはリスクが伴う可能性があり、コントローラーはビジネス ロジックが滞留する理想的な場所ではありません...JUnits を実行するのは非常に難しい (あなたの入力はリクエストです...)

ビュー

非トランザクション (非遅延コレクション/メンバーにアクセスすると、遅延初期化例外が発生します)

長所:

  • ビューの作成者は、単なるドット表記によってアプリケーションのパフォーマンスに影響を与えるべきではありません (例:大規模なコレクションの遅延初期化により、N+1 選択が発生します。

  • また、切断されたクライアント (Flex またはその他のリッチ クライアント) では、リモートでの遅延初期化はサポートされていないか、賢明な方法ではありません。

短所:コントローラー/サービス/DAO は、ビュー用のエンティティの適切なグラフを慎重に準備する必要があり、オーバーシュート (パフォーマンス) またはアンダーシュート (遅延初期化例外) が発生する可能性があります。エンティティ グラフを初期化できる順列の数にはデカルト積があるため、無数のサーバー側メソッドが混乱を引き起こす可能性があります。

モデル

永続オブジェクトをそのまま使用すると (データ転送オブジェクトなし)、状態はセッションに保存されます。

長所:POJO を書き換える必要がなく、既存のエンティティを再利用できるため、セッション状態は隠しフィールドの状態処理よりも安全です。

短所:切断されたフレームワークには不利で、切断された古いオブジェクトを保存するリスク、ロックの問題のリスク、他のデータを上書きするリスクがあり、場合によっては楽観的なロックが必要になります。

サービス

トランザクションは、リクエストのスコープを知らず、実際の永続ストレージ アクセスのために DAO レイヤーを呼び出します。これは古典的に BL があるべき場所ですが、BL が何度もコントローラー側に漏れているようです。

ダオ

BL やコンテキストを無視したアトミック永続ストレージ ファサードが含まれています

最後に質問です。

上記のアーキテクチャで何を修正しますか?

あなたは（私と同じように）これが非常に一般的なアプローチだと思いますか（オープンセッションが表示されるなど、いくつかの小さな違いはありますが）？それとも、初めて見たのに、私が何かひどく間違ったこと（または正しいこと）をしているのでしょうか？

アプリケーションでそれをどのように解決しますか?モデルやビューにもエンティティ POJO を使用しますか?それとも、より単純な UI Bean (すべて完全に初期化され、安全な) に接続しますか?

これは主観的な質問かもしれませんが、1、2、または最大 3 つの一般的な「宗教」に分類される明確なベスト プラクティスの設計パターンがあると私は確信しています。

役に立ちましたか？

解決

は全体的に、それは非常に良いアーキテクチャのように思えます。あなたはすでにそれを読んでいない場合は、私はあなたの質問にすべての対象を記述するエンタープライズアプリケーションアーキテクチャのマーティンFowlersパターンを、推薦ます。

あなたのパフォーマンスがあることを期待どのように大きな問題質問から明らかではありません。あなたは彼らがいると思うと、すぐにあなたがそれらを見つけるところ私の経験では、パフォーマンスのボトルネックはめったにありません、簡単にそれが一致するようにアーキテクチャを変更することがあります。

あなたは、テスト容易性が主要な関心事であることを右です。私はいくつかの成功を収めてパッシブビューの-patternマーティンFowlersを使用していました。また、同じサイトから、コントローラの監督を見てみなければならない。

他のヒント

SOFEA スタイルのフロントエンドを実行しない限り、これは基本的に上記のアーキテクチャのコントローラー部分を削除します。

フロントエンドは完全にクライアントに含まれており、REST サービスまたは SOAP サービスを直接呼び出して JSON または XML を返します。これで、表示用のドメイン オブジェクトの変換に関する問題が 100% 解決されるようです。

おそらく、上記の N 層アーキテクチャに対する明確な解決策がない理由は、それが明らかに間違っているからであると示唆する人もいます。

リンク

  1. http://raibledesigns.com/rd/entry/sofea_only_known_as_soui
  2. http://www.theserverside.com/news/thread.tss?thread_id=47213
  3. http://wisdomofganesh.blogspot.com/2007/10/life-above-service-tier.html

私の現在のプロジェクトでは、データ転送オブジェクトを備えたやや時代遅れの N 層アーキテクチャを使用しています。アプリケーションは配布されず、今後も配布されないため、DTO は不要です。DTO を使用する 1 つの利点 (個人的には価値がありません) は、ビジネス メソッドにクリーンなインターフェイスが強制されることです。View コンポーネントは、希望に応じて疑似モデル上のオブジェクト グラフを横断できます。遅延初期化例外は発生しません。投げられる。

私たちのアーキテクチャで私が感じるアーキテクチャの問題点の 1 つは、ビジネス インターフェイスが 2 つの非常に複雑なことです。小さなビジネス インターフェイスをすべてカプセル化するには、メタ ビジネス インターフェイスが必要であるように思えます。実際、これは、1 つのサービスがその作業を実行するために他の 3 つのサービスを呼び出すことになる場合に発生します。

コントローラー (この場合、Struts 1.2 アクション クラス) は、最終的に、これらの超粒度または粗粒度のビジネス コンポーネントを任意に組み合わせて呼び出すことになります。残念なことに、ほとんどの場合、開発者は、コントローラー クラス内にビジネス ロジックであるべきさまざまなコードを無意識に、または怠惰にコーディングしてしまいます。これらの 300 行のアクションメソッドの 1 つを見るたびに叫びます!!!!

SOFEA アプローチは、よりクリーンなアプローチを提供しているようです。AJAX を使用すると、ブラウザ上で実行されている Web アプリケーションでも、適切な MVC パターンを使用してフロントエンドをコーディングできるため、ユーザー (より動的な UI を提供する) と開発者 (適切な MVC をコーディングできる) の両方にとって有益です。

UI は、再利用可能なビジネス ロジックから完全に分離されています。GUIは厚いのか薄いのか？それは実際には問題ではありません。基本的に同じ方法でコーディングされます。

SOFEA / SOUI は私にとって初めてで、試したことはありませんでしたが、最近それについて読んだので、私の考えを共有したいと思いました。

上記のアプローチは良さそうです。

ただし、UI-Beans を使用する必要があると思います。もちろん、この UI-Bean は事実上不変である必要があります。作成後すぐにその状態 (およびカプセル化されたドメイン オブジェクト) を変更しないでください。

非常に単純化した例:


class UIBean {
  DomainObject o;

  public String getDescription(){
     return trimToSummaryText(o.getDescription());
  }

  private static String trimForSummaryText(){
     ....
  }
}

主な長所:

  • テンプレート コードはよりクリーンで簡潔になる傾向があります。フロントエンド開発者はこれに満足するでしょう。
  • フロントエンド固有のヘルパー メソッドをドメイン オブジェクト クラスに追加する傾向はありません。
  • 異なるドメイン オブジェクトまたはビュー Bean のグループ化が可能です (ui-Bean は複数のフィールドを持つことができます)。ここではリストのカプセル化が特に優れています。

はい、そのためにはさらに多くの Java クラスが必要です。ただし、この抽象化レイヤーは、Web アプリやページが成長しても、ほぼ常に問題ありません。

質問は去年ほど前に答えたにも関わらず、

は、おそらくその答えは、誰かに役立つ表示されます。 通常レイヤーの（例えばビューおよびサービス）の代わりに、UiBean-SそれほどのDTO と呼ばれ、上記の間でデータを受け渡すための：総合あなたが概説アーキテクチャ追加するだけで、詳細は、結構です>（データ転送オブジェクト）が使用されており、これらは該当するフィールド/セッター/ゲッターと無地のPOJOです。

のJava EE仕様の以前の/初期のバージョンのいずれかで「DTO」という用語は、誤って、彼らは少し異なる目的を持っているものの、「ValueObject」と混合した。

希望、このことができます。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top