単体テストの利点以外に、MVP パターンについて聞いたのは、プレゼンテーション レイヤーの再利用性です。したがって、1 つのプレゼンテーション レイヤーを設計し、それを WinForms (リッチ) と Web に使用します。
私は現在、.NET で Windows フォーム アプリケーションに取り組んでおり、将来的には Web UI を作成する可能性があります。しかし、プレゼンテーション レイヤーと UI レイヤー間の相互作用を設計している場合、この再利用性の概念に苦労する価値があるかどうかは定かではありません。Windows フォーム UI 用に特別に設計された場合はさらに多くの可能性がある場合、可能性のある Web UI のプレゼンテーションを「馬鹿げている」ように感じることがあります。
では、再利用可能なプレゼンテーション レイヤーのメリットを享受している人はどれくらいいるでしょうか? この再利用可能性は現実の世界でうまくいきますか?
MVC / MVPの価値は、実際には2つの異なる分離にあります。
プレゼンテーション層とモデルの分離（ただし、それらを実装することを決定した場合）は、単純なシステム以外のソフトウェア設計の最も重要な原則の1つです。アプリケーションにビジネスロジックまたは非ビジュアルロジックがある場合は、その分離の利点を確実に理解できます。
プレゼンテーション層とコントローラーの分離は、私には少し重要ではないようです。リッチクライアントアプリケーションでは、この分離によるメリットはめったにありません。Webフロントエンドでは、はるかに一般的です（たとえば、ASP.NETaspxと分離コードまたはJ2EEjspxとサーブレット）。
あなたがMVPを説明した方法を完全には理解していないかもしれませんが、利点の1つがプレゼンテーション層の再利用性であるとは言えません。むしろ、主な利点はモデルの再利用性であると言えます。 。これは、n層システムを使用する主な利点の1つでもあります。新しいタイプのフロントエンド（WinForms、WPFなど）を拡張して構築する場合は、構築したばかりのWebアプリケーションからすべてのロジックを分離しようとせずに実行できます。
私は chills42 に同意します。MVP の目標は、プレゼンターを非常に一般的なものにして、あらゆる UI テクノロジで使用できるようにすることではありません。目標は、モデルと (おそらく) コントローラーを汎用化し、必要なテクノロジを使用して UI を構築できるようにすることです。
繰り返しますが、私はあなたを誤解している可能性がありますが、データバインディングはあなたの質問に特に関連していません (つまり、接続がわかりません)。目的はこれです：
コントローラーとも呼ばれるアプリケーション ロジックを設計します (たとえば、Bob が請求書を送信すると、システムは x、y、および z を実行し、Bob に請求書のリストを表示します)。
モデルとも呼ばれるビジネス データを設計します (明細項目のリストを含む請求書など)。
さて、UI は一体どこにあるのだろうか？プロセスをガイドする方法を知っているものと、それを実行するために必要なすべてのデータがあるので、すべてがどのように見えるかを示すものだけが必要です. ここでプレゼンターの出番です。
コントローラーとモデルとのインターフェイスとなる .NET WinForms アプリケーションを設計します。請求書を作成する方法をユーザーに提供する美しいフォームを作成します。次に、すべてのデータをコントローラーに渡します。コントローラーはそれを受け取り、モデルを使用して処理し、次に何をすべきかを指示します。WinForms アプリは喜んで (何も知らされずに) 楽しく進み、言われたことを実行して、次のフォームのデータを受け取り、それを表示します。
その後、上司がやって来て、「ハン ジホさん、あなたのこのアプリケーションは完全に成功しています。ASP.NET アプリケーションと、これらすべてを実行するバッチ プロセッサも構築する必要があります。
くだらない。彼はあなたに何を望んでいますか？ああ、問題ありません。MVPを使用しました。必要なのは、すべてのデータの見栄えとして機能する ASP.NET UI (もちろん、Web 標準に準拠しています) を構築することだけです。問題ありません。3 日以内に発送してください。
これが MVP の利点です。すべてのアプリケーション ロジックを書き直す必要はありませんでした。データを別の形式に変換するために大量のクエリを記述する必要はありません。本当に何もする必要はありませんでした。UIを作るのは楽しいですよね。これが時間の価値があると考えるかどうかを判断するのはあなた次第ですが、ほとんどすべての実際のソフトウェアでは、MVP であろうと n 層のようなエンタープライズ向けのものであろうと、これらのコンポーネントを何らかの形で分離することが期待されています。
役割やプレゼンターを誤解している可能性があると思います。
プレゼンターは、UI、つまり情報の表示方法とはほとんど無関係であるべきだと私は主張します。
プレゼンターは、UI (Web または WinForm) から入力を受け取り、コントローラー レベルで必要な処理を開始し、出力を保持する必要があります。
UI は、その戻り値の使用方法を完全に制御する必要があります。
例：
車に関するデータベースからデータを取得しているとしましょう。
UI からプレゼンターに車両識別番号を渡し、データを返すように依頼することができます。処理が完了すると、返されたデータが保持されます。メーカー、モデル、年、および最終登録日があると仮定しましょう。
あなたの UI から、これを好きなように表示できるはずです。これにより、プレゼンターが再利用可能になります。winform では 4 つの項目すべてを表示できますが、モバイル用の Web UI では基本情報 (メーカー、モデル、年) のみを表示できます。
あなたの「だるい」という気持ちは絶対に正しいと思います。
再利用性は、プロジェクトが消える可能性のある最も深く、最も暗く、厄介なネズミの穴の 1 つです。約 15 年間の OO 開発の経験から言えば、再利用性は私たちが得られる主な利点の 1 つとして宣伝されました。
再利用のための設計は、パフォーマンスのための設計と似ています。これは、背景となる基本原則であるべきですが、ほとんどの場合、前もって注意を払いすぎると、開発プロセスが滞り、すべてを過度に一般化することになります。
私の通常の推奨事項は、最初に最も複雑で柔軟な GUI を実装してから、より再利用可能な汎用アーキテクチャにリファクタリングすることです。プロジェクトの規模に応じて、何を評価するかについていくつかの明確な目標を設定したプロトタイプでこれを行います。その後、プロトタイプをアーカイブして保持しながら、学んだ教訓といくつかのコードをメイン プロジェクトに戻すことができます。
注: GUI アーキテクチャを検討している場合のプロトタイプは、使用しようとしているテクノロジを使用する必要があり、GUI のルック アンド フィールを示すために行われる従来の GUI プロトタイプよりも深くて狭いものです。
私が再利用のストーリーを購入したのは、一度はうまくいったからです。また、あるタイプの UI からまったく別のタイプの UI に交換するのが簡単だとは思わないからです。
一般的に、そしてあなたの場合、プレゼンターをかなり変更する必要があると思います。そして、それは大丈夫です、それがそこにあるものです。これは基本的に、UI とドメイン ロジックの間のアダプターです。また、ドメイン ロジックを UI から除外するのに役立つため、UI の交換がはるかに簡単になります。
ああ、ところで、Web アプリは非常に強力になり始めています。Web 用に Presenter をスマート化する必要があるかもしれません。
マイク
MVC 設計によって提供される再利用性は、同じビュー/プレゼンターが同じモデル/コントローラーを異なる出力に表示できるというものではなく、異なるモデル/コントローラー セットを共通のビューに表示できるというものではありません。
システムが成熟するにつれて、いくつかのビューが必要になる可能性があります。Web インターフェイス、デスクトップ エディター、自動化されたスクリプト API、およびいくつかの異なるモデルです。顧客 A の請求は注文ごとですが、顧客 B はそれを必要とします。顧客部門ごとに四半期ごと。
MVC は、1 つのフロントエンドだけに使用することになる場合でも、使用するのに適したパターンです。きれいに分離されたパーツでアプリケーションを設計するのに役立ちます。これにはいくつかの利点があります。
たとえば、GUI を必要とせずにモデルを直接呼び出すことができるなど、パーツの自動テストが容易になります。
明確な分離線があるため、アプリケーションの一部を再設計しやすく、他のコードを壊すことはありません (たとえば、GUI の再設計など)。
1 つの大きな寄せ集めではなく、いくつかの小さな (そして可能な限り独立した) パーツを使用すると、デバッグが容易になります。
一度に 1 つのロジック部分を探索できるため、新しいプログラマーをコードに紹介するのが簡単になります。
一般的に言えば、MVC はアプリを高レベルでカプセル化する自然な方法を提供するため、アプリケーションを設計するための良い OO 方法です。
悪寒42、
役割やプレゼンターを誤解している可能性があると思います。
プレゼンターの役割をよく理解していると思います。
プレゼンターをジェネリックにして、どの UI でも機能することは間違いありません。私の質問は、特定の UI プラットフォームが提供できる利点を利用する機会を失う一方で、それが努力する価値があるかどうかです。
WinForms でのデータバインディングを考えてみてください。特定のインターフェイス ( IDataErrorInfo、INotifyPropertyChanged、IEditableObjectなど) を実装することで、プレゼンターはより少ないコードで UI をよりシンプルにすることができます。データバインディングは利点ではないと言う人もいるかもしれません - それは的外れです。これらのインターフェースの多くは Web にとって意味がありませんが、Web にとって害はないでしょう。データバインディングの目的で、WinForms 用のアダプターを作成できます。だから私は別の層を持っています。問題は、努力する価値があるかどうかです。
あなたは自分自身をうまく説明しています。心配はいりません。:)
アプリケーション ロジックとビジネス ロジックを混同しないように注意してください。アプリケーション ロジックは、アプリケーション プロセス コントロールと呼ばれることもありますが、これはおそらくより適切な名前です。これは基本的に、ユーザーのアクションとシステムの応答です。たとえば、ステップ 1: ユーザーがログインする、ステップ 2: ユーザーが [Create New Invoice] をクリックする、ステップ 3: ユーザーが基本情報を送信する、ステップ 4: ユーザーが項目を追加する、ステップ 5: ユーザーが請求書を請求書データベースに送信する、などです。
以下に概説する手順は、請求書アプリケーション用に設計するすべての UI に適用されるプロセス制御です。一方、ビジネス ロジックはモデルにカプセル化されます。P はプレゼンテーション用ですが、プレゼンテーションロジック用ではありません。ほとんどの場合、P はクライアント向けコンテンツ (たとえば、ASPX、JSPX、Ruby on Rails ビューなど) を指します。これは厳密にはマークアップです。つまり、コントローラーはプレゼンテーション レイヤーに何らかの動作を提供します。
これらの定義を考えると、コントローラーとモデルを適切に作成した場合、完全に UI にとらわれないことがわかるでしょう。最小公分母はプロセス ロジックとビジネス ロジックをカプセル化するだけなので、最小公倍数に対応する必要はありません。プレゼンテーション レイヤーは、そのロジックを公開する媒体 (インターネット、コンソール、デスクトップなど) に対応できます。アプリケーション)。
補足として、コントローラーとモデルは実際には他の抽象化された方法 (Web サービスなど) で公開されることがあるため、多数の UI や Web サーバーを使用して着信トラフィックの一部のバランスを取ることができ、同じバックエンドを引き続き活用できます。 .
これが少し役立つことを願っていますか？
エド・アルターファー
あなたがコントローラーと呼んでいるものに少し混乱しています。
コントローラーとも呼ばれるアプリケーション ロジックを設計します (たとえば、Bob が請求書を送信すると、システムは x、y、および z を実行し、Bob に請求書のリストを表示します)。
モデルとも呼ばれるビジネス データを設計します (明細項目のリストを含む請求書など)。
しかし、あなたのステートメントでは、コントローラーはアプリケーション ロジック (ビジネス ロジック?) を含むものであり、モデルは単なるデータ ホルダーのようです。
私が理解していることから、P はプレゼンテーションの略です。P は、プレゼンテーション ロジック、つまり、基礎となるビジネス情報をユーザーに提示する最善の方法に関心があります。実際のビジネス ロジック/ルールは、モデル レイヤーに含まれます。実際、コントローラーと呼ばれるものも、モデル レイヤーの一部である M.
いずれにせよ、「要求の厳しい」上司に関するあなたの例は、教科書から外れているように思えます-私たちは皆、これを知っています. それは私が主張していることではありません。
繰り返しますが、P がプレゼンテーション用である場合、WinForms と Web は、プレゼンテーションのニーズに対して完全に異なるフローを持っている可能性があります。Pレイヤーさえ必要ないバッチアプリ用のコンソールは言うまでもありません。データバインディング技術が設計どおりに機能すると仮定すると、データバインディングにより、WinForms UI レイヤーが非常に単純になります (V)。データ バインディング アプリと非データ バインディング アプリのソースを比較してみてください。非データバインディングのシナリオでは、自分で管理しなければならない可動部分が増えます。より多くのことを制御できますが、それでも管理する必要があります。私の意見では、データバインディングは、P.
1 つの P レイヤーをすべての種類の UI で機能させることができることに異論はありませんが、残念ながらそうしている間は、すべての UI の最小公分母について妥協する必要があります。また、より多くのプレゼンテーション ロジックを UI レイヤーにプッシュしている可能性もあります。これにより、単体テストがより困難になります。
それが私の最初のジレンマを明確にしたことを願っています。自己表現力が足りないのかも…。