問題タブ [mvp]

多くのツールが推奨するユーザーインターフェイスを構築するRAD （ドラッグアンドドロップと構成）の方法を超えて見ると、 Model-View-Controller、Model-View-Presenter、Model-View-ViewModelと呼ばれる3つのデザインパターンに出くわす可能性があります。私の質問には3つの部分があります。

1. これらのパターンはどのような問題に対処しますか？
2. それらはどのように似ていますか？
3. それらはどう違いますか？

現在、UIからASP.Netアプリを作成しています。私はWinformsにうんざりしていて、関心の分離がより優れたものが欲しかったので、MVPアーキテクチャを実装しています。

したがって、MVPを使用すると、プレゼンターはビューによって発生したイベントを処理します。ユーザーの作成に対処するために私が用意しているコードは次のとおりです。

組み込みの.Net検証コントロールを使用してメインフォームの検証を実行しましたが、データがサービスレイヤーの基準を十分に満たしていることを確認する必要があります。

次のサービスレイヤーメッセージが表示されるとしましょう。

• メールアカウントは既に存在します（失敗）
• 入力した参照ユーザーが存在しません（失敗）
• パスワードの長さがデータストアの許容長を超えています（失敗）
• メンバーが正常に作成されました（成功）

また、UIが予測できないより多くのルールがサービスレイヤーに含まれるとしましょう。

現在、計画どおりに進まなかった場合、サービスレイヤーに例外をスローさせています。それは十分な戦略ですか？このコードはあなたたちに臭いがしますか？このようなサービスレイヤーを作成した場合、このように使用するプレゼンターを作成する必要があることに悩まされますか？リターンコードは古すぎるように思われ、ブール値は十分な情報を提供しません。

OPではなく編集：OPによって回答として投稿されたフォローアップコメントにマージ

Cheekysoft、ServiceLayerExceptionの概念が好きです。予期しない例外のためのグローバル例外モジュールがすでにあります。これらすべてのカスタム例外を面倒にすると思いますか？基本の例外クラスをキャッチするのは少し臭いと思っていましたが、そこからどのように進行するのか正確にはわかりませんでした。

tgmdbm、ラムダ式の巧妙な使用が好きです！

フォローアップしてくれたCheekysoftに感謝します。したがって、例外が処理されない場合にユーザーに別のページ（私は主にWeb開発者）が表示されることを気にしないのであれば、それが戦略になると思います。

ただし、ユーザーがエラーの原因となったデータを送信したのと同じビューでエラーメッセージを返したい場合は、プレゼンターで例外をキャッチする必要がありますか？

PresenterがServiceLayerExceptionを処理したときのCreateUserViewは次のようになります。

この種のエラーの場合は、同じビューに報告すると便利です。

とにかく、私たちは今、私の最初の質問の範囲を超えていると思います。あなたが投稿したものをいじってみます。さらに詳細が必要な場合は、新しい質問を投稿します。

大学に通い、SO の開発を追っているうちに、Model-View-Controller アーキテクチャ デザイン パターンについて多くのことを耳にしました。MVC パターンが何であるかを理解する前に、うっかり MVC パターンを使用してしまい、今でも毎日の仕事で使用しています。私が見た限りでは、これはおそらく今日使用されている最も人気のあるパターンです。私があまり聞いたことがないのは、MVC の代わりに使用できる代替パターンです。どのようなオプションがあり、どのような理由で MVC よりもそれらを使用することにしますか? また、それらが使用される典型的なシステムの種類を知りたいと思っています。最後に、それらを使用することに伴う長所と短所は何ですか?

私が構築している (実際には再構築している) 大規模な ASP.NET アプリケーションで MVP パターンの使用を開始したばかりで、ビューに適用されるイベントをどのように使用すべきかを理解するのに苦労しています。

ユーザー コントロールに 2 つのドロップダウン リストがあり、一方が他方の値に依存しているとします。

インターフェイスで AutoPostBack イベントをどのように定義する必要がありますか? 次のようにユーザーコントロールによって処理されるイベントである必要があります。

または、インターフェイスでイベントを定義する必要がありますか? これが望ましいパターンである場合、処理および使用するイベントを追加するにはどうすればよいですか?

単純なWebForms（asp.net）ベースのUIをテストし、MVPパターンに従って、UIをよりテストしやすくしようとしています。

バックエンドアルゴリズムのTDD方法論に従うと、DRY原則（Do n't Repeat Yourself）の精神で行われる単体テストのリファクタリングがいくつかあることがわかります。Rhino Mocksを使用してこれをUIに適用してインタラクションを検証しようとすると、ビューまたはモデルの期待値を設定するときに、コントローラーテストに多くの共通点が見られます。

私の質問は、もしあったとしても、通常、このリファクタリングをどこまで行うのかということです。他のTDDerがMVC/MVPベースのUIをどのようにテストしているかを知りたいです。

MVPをSilverlightで動作させる方法についてのアイデアはありますか？ロードイベントが発生しないという事実を回避するにはどうすればよいですか？

これは私が持っている見解です：

そして私のプレゼンター：

Loadedイベントが呼び出されないようであるため、何も起こりませんでした。これを回避するにはどうすればよいですか？

asp.netアプリケーションで、Webクライアントソフトウェアファクトリー（WCSF）とそれに関連するモデルビュープレゼンターパターン（MVP）の使用を、ページメソッドと組み合わせたいと思います。ページメソッドは、でマークされた.aspxビューの静的メソッドです。 [WebMethod]属性。

ただし、aspxページの静的メソッドは、ビューが通信するために必要なプレゼンターとコントローラーのコンテキストを持つためにページ上にインスタンスメソッドが必要であるため、モデルビュープレゼンターパターンを壊すように見えます。

ページ上の[WebMethods]、別名ビューをサポートするために、WCSFでasp .netのMVPパターンをどのように拡張しますか？

私は最近、パッシブ ビュー アプローチで MVP パターンに切り替えました。TextBoxes にマップされた文字列、DropDownLists にマップされた IDictionary、一部のグリッドにマップされた IEnumerable、リピーターなど、ビュー インターフェイスが基本的な clr 型のみを公開する場合、非常に快適に作業できます。

ただし、この最後のアプローチは、それらのグリッドから 1 つの列のみを気にする場合にのみ機能します。グリッドの複数行のコンテンツを IView 内にマップするにはどうすればよいですか? 今のところ、2 つの解決策が頭に浮かびますが、どちらも素晴らしいものではありません。

1. グリッドのコンテンツ用の DTO を作成し、IView で IEnumerable を公開するか、または
2. IView のように、IEnumerable または単に「グリッド」を公開します。

最初の解決策は、監視コントローラー パターンに近づきながらパッシブ ビューのルールを破っているように見え、2 番目の解決策は MVP パターン全体をまったく破っています。これをどのように処理しますか？

ありがとう、ウカシュ

私は MVP スタイルで Windows フォーム アプリケーションを実行しようとしていますが、これまでスレッド化をあまり行っていなかったので、混乱しています。

私の UI は非常に単純なフォームのセットです。各フォームはインターフェイスを実装し、ビジネス ロジック レイヤーに存在するメディエーター クラスへの参照を含み、その逆も同様です。したがって、簡略化された図は次のようになります。

ご覧のとおり、メディエーター クラスは UI を制御し、データの表示、起動、終了などのタイミングを伝えます。モーダル ダイアログを表示するタイミングと閉じるタイミング (上記の PleaseWaitDialog) も指定します。 UI は、画面にデータを表示し、入力をメディエーターに中継します。

このアーキテクチャは素晴らしく分離されており、テストとプロトタイプ作成が非常に簡単です。すべてをまとめているので、スレッドの問題が発生し始めています。たとえば、メディエーターによって制御されるタイマーが 5 秒カウントされるまで (ShowDialog() を使用して) CheckInForm の上にモーダル フォームとして PleaseWaitDialog を表示する場合 (これは単純化されていることを思い出してください)、クロススレッド エラーが発生します。タイマーのコールバックから PleaseWaitDialog.Close() を呼び出した場合。同様に、モーダル ダイアログでユーザーが UI を操作するのをブロックする場合、別の方法 (確認ダイアログなど) を指定しない限り、ビジネス レイヤーでのアクティビティをブロックしたくありません。

私がやりたいと思っていることは、メディエーターとビジネス ロジックをメイン スレッドで実行し、UI を完全に別のスレッドで実行することです。

2 番目の質問は、別のスレッドでクラスを実行するなどの方法を教えてください。そして、どうすれば2人に通信させることができますか? 私は .NET スレッドについて読み進めていますが、締め切りがあり、メイン スレッドのクラスで UI を含むスレッドを生成し、それらのオブジェクトが互いに通信するようにする方法の例がいくつかあります。

どちらを選択するか（MVCまたはMVP）を尋ねているのではなく、2つのうちの1つをWebアプリケーションに使用する必要があるかどうかを尋ねていることに注意してください。

古いアプリケーションを現在の設計からMVCまたはMVPパターンに変換するのは大変な作業かもしれないことを私は理解しています。しかし、新しいアプリはどうですか？これらは最も人気のあるアーキテクチャパターンのようですが、そのうちの1つを選択する必要がありますか？そうでない場合、他にどのようなパターンがありますか？

MVCやMVPに精通していない場合は、「MVPとMVCとは何ですか、違いは何ですか？」を確認することをお勧めします。。それぞれを分解するさまざまなウェブサイトへのリンクを含む、多くの良い答えがあります。