5

データレイヤーとビジネスレイヤーの抽象化に成功しました。しかし最近、ある同僚が、UI 層とビジネス層の間の UI 層の抽象化について言及しました。しかし、私はそれを理解することはできません。この UI レイヤーがビジネス レイヤーとどのように異なるかを視覚化することはできません。私は記事のために十分にゴーグルしましたが、あまり助けがないようです. 誰かが簡単な例を教えてもらえますか?

4

4 に答える 4

1

以前、 Jeremy Miller のBuild Your Own CABシリーズの記事が非常に参考になりました。彼は、Model-View-Controller ファミリーのパターンのさまざまなバリエーションについて説明しています。読みごたえ抜群です。

于 2009-01-08T16:27:10.757 に答える
1

ここには複数のオプションがあります。

  1. MVC

    ビューをモデルとコントローラーから分離する必要があります。なぜこれを行うのかを想像する最も簡単な方法は、異なるビュー (Web サイト ビュー、スタンドアロン アプリケーション ビュー、Web サービス ビュー、携帯電話ビュー、ユニットテストビューなど。したがって、ビューコードにロジックは必要ありません。つまり、Java では、ActionListeners やその他の GUI コード内でモデルを操作する必要はありません。代わりに、それをコントローラー クラスに移動すると、ビュー ハンドラーは単純に入力の検証、出力の書式設定、およびコントローラー クラスとの対話を行います。

    多くのビューは、ビュー中心のアプローチから作成されています。あなたはあなたのGUIを持っています。何かが起こり、それに反応して何かを行い、必要に応じて GUI を更新します。したがって、ビジネス ロジックとモデルをビューに非常に緊密に結びつけるのは簡単です。

    基本的に、ビジネス ロジックに任意のインターフェイスを作成して呼び出すことができるため、新しいビューを簡単に追加できます。これらのインターフェイスは、呼び出す必要のあるすべての関数を提供します。その後、内部ビジネス ロジックを非公開にすることができます。

  2. データ収集 Web フォーム (または一連の Web フォーム)

    ビジネス層のデータ モデルと同じ順序で情報を収集することはほとんどありません。さらに、複数ページ フォームのページ間で永続化する必要があります。これらの非 null 制約は、ページ 3 でそれらを収集しているときに PITA であることがすぐにわかります (顧客をページ 1 から遠ざけるため)。フォームは再配置されると変更される可能性があるため、かなり早い段階でビューからビジネス ロジックを分離し、モデルにデータを入力する方法を一般化することになります。そして、他の多くのもの。

  3. モデルから生成されるインターフェース

    明示的または暗黙的に変更できるモデル、または実際にインターフェイスを記述するモデルがあります。したがって、事前に設計されたフォームやウィンドウなどを使用する代わりに、モデルからインターフェイスを生成します。この方法では、作業するモデルしかないため、ビューコードを非常に一般的にプログラムする必要があります。モデルから UI へ、およびその逆の多くのマップ。次に、モデルの値が他の場所で変化するため、いくつかのオブザーバーを追加します。これはとても楽しいです... :)

  4. 他の何か...

于 2009-01-08T15:58:18.163 に答える
0

簡単に言えば、UI レイヤーは、UI と次のレベル (おそらくビジネス レイヤー) とのコラボレーションにのみ関係します。ビジネス レイヤーとデータ レイヤー (およびその他のレイヤー) には、UI レイヤーの仕事であるため、UI コードを含めることはできません。

Web ブラウザーの仕組みを考えてみてください。ブラウザーは UI レイヤーであり、ページのレンダリングのみに関与します。何かを行う必要がある場合、Web サーバー (次のレイヤー) を呼び出してこれを実行し、結果をレンダリングします。

いくつかのよく知られている UI パターンをグーグルで検索してみてください。

  • MVC
  • MVP
  • 控えめなダイアログ ボックス

    • 于 2009-01-08T15:49:00.633 に答える
    0

    私の原則は次のとおりです。(フォーム コントロールの操作以外の) ロジックを書き直す必要がある場合は、UI レイヤーを他のレイヤーから完全に分離していません。個人的には、ビジネス ルールを保持し、ドメイン オブジェクトとデータ マッピング オブジェクトを操作し、UI でドメイン オブジェクトを交換するだけのサービス レイヤーが必要です。その場合、UI はデータマッピングやビジネス ルールについて何も知りません。

    UIと私のサービス層の間の別の「UI層」については答えません。おそらくこれは、HTML とコードを分離しておくという観点からです (つまり、ASP.Net のコード ビハインドは UI レイヤーと見なされる可能性があります)。マークアップが千の異なる機能で断片的に構築されている場合、グローバル HTML 設定を変更しなければならないことほど (Web アプリの変更/デバッグにおいて) 悪いことはありません。HTML は、それらをクラスに関連付けるために必要な最小限のスクリプトを使用して、HTML ファイルにする必要があります。

    于 2009-01-08T20:12:55.123 に答える