タグ付けされた質問 「mvp」

Model-View-Controller（MVC）およびModel-View-Presenter（MVP）パターンについて3日間読んでいます。そして、私を非常に悩ませる1つの質問があります。既にMVCがあったのに、ソフトウェアデザイナーがMVPを発明したのはなぜですか？ MVCが解決しなかった（またはひどく解決した）が、MVPが解決できる問題は何ですか？MVPが解決するのはどの問題ですか？ MVPの歴史と説明、またはMVCとMVPの違いに関する記事をたくさん読んでいますが、私の質問に対する明確な答えがありませんでした。 私が読んだ記事の1つで、次のように言われました。 次に、Model View Presenterを使用します。これは、最新のコンポーネントベースのグラフィカルユーザーインターフェイスに適用した場合のMVCパターンの不備に対する応答でした。最新のGUIシステムでは、GUIコンポーネント自体が、中央のコントローラーではなく、マウスの動きやクリックなどのユーザー入力を処理します。 だから、理解できませんが、実際には別の方法で、GUIコンポーネントがユーザー入力を自分で処理しないようにすることはできますか？そして、「自分で処理する」とはどういう意味ですか？

49 design  design-patterns  mvc  mvp 

Androidでビューとプレゼンターを分離する方法、ユーザーアクション（MVPのプレゼンター部分）に対する反応は、GUI要素（MVPのビュー部分）を表示する同じアクティビティに設定されます。 「Martin FowlerやMichael Feathers [2]が言うように、モデルビュープレゼンターでは、UIのロジックはプレゼンターと呼ばれるクラスに分離され、ユーザーからのすべての入力を処理し、「ダム」ビューにディスプレイ」（ここから引用）。 今まで、Androidの主な機能の1つは、アクションを実行し、それらに反応して結果を表示するスマートアクティビティであると考えていました。MVPスキームはAndroidの哲学と矛盾していますか？Androidでそれを実現しようとするのは理にかなっていますか？はいの場合、どのようにそれを行うことができますか？

34 android  mvp 

モデルビューコントローラー、モデルビュープレゼンター、モデルビューViewModelなどについて読んでいますが、一般的に、基本的な概念は非常に理解しやすいようです。可能。デザインチョコレートにロジックピーナッツバターは含まれていません。クール、私はそれが好きです。 問題は、その3番目の部分についてはまだ少し曖昧だということです...モデルまたはビューではありません。誰もがそれを何と呼ぶべきか、何をすべきか、何が適切で、何が間違っているのか、自分の考えを持っているようです...それはプレゼンターの仕事だからです。 私はとりとめのないです。 それらの違いを誰かに説明するように頼むのではなく、すでに何度も行われているので（私は知っています;数え切れないほど多くの記事を読んでいます）-私は私は自分でモデルを作った少数のプログラマーです。 そうは言っても、このデザインをどのように分類しますか？そしておそらくもっと重要なことですが、これについて明らかに悪いことはありますか？確かに、これが本当に堅実な設計であれば、私は良いことをしていると聞きたいと思いますが、賞賛よりもむしろ堅実なアドバイスを与えられるでしょう。 注：Model-View-の神秘的な3番目の部分に「ブリッジ」を使用しますか？それが「すべき」であるという潜在意識の提案を避けるため。 モデル データに対する権限です。 リクエストされた変更に関する情報をブリッジから受け取ります。 データが他のデータにどのように関連するかについてのすべてのロジックを含み、実行します。 データが変更されたときにブリッジに通知します（ブリッジが関心を示したデータについて）。表現の編集：外部のサブスクライバー（何も知らない）が、その状態または計算結果をモニターできるようにします。 ビューに関する知識がありません。 見る ユーザーにデータを表示および操作する方法を提供することに関心があります。 ブリッジからデータ更新に関する情報を受け取ります。 ユーザーにデータとコントロールを提示する方法のすべてのロジックを含み、実行します。 ユーザーがモデルに（おそらく）影響を与えるアクションを実行したときに、ブリッジに通知します。 興味のある情報をブリッジに通知します。 モデルに関する知識がありません。 ブリッジ モデルとビューの間のコーディネーターおよびトランスレーターです。 モデルとビューの間で受け渡される情報に適切なフォーマット変更を加えます。 「誰が何を知る必要があるか」に関する情報を保持します。 モデルとビューの両方の知識がある。 その他の注意事項 より複雑なプログラムでは、複数のモデルが存在するのが一般的です。この状況では、ブリッジは通常、複数のモデル間の調整/翻訳の仕事を引き受けるため、protocall / API / designモデルの構築対象の権限になります。（たとえば、カードゲームプログラムを構築し、代替のデッキシャッフルモデルを構築する場合、ブリッジを使用して、ブリッジとの適切な通信に必要な機能を決定する必要があります。） ビューとモデルが1つだけの小さな単純なプログラムでは、ブリッジがどちらの側でどの機能を使用できるかを「想定」するのが一般的です。ただし、プログラムがより複雑になると、非効率性とバグのある仮定を回避できるように、ビューとモデルが機能をブリッジに報告することをお勧めします。 ほぼカバーしていると思います。どうしても、私が使用する傾向のあるデザインについて質問がある場合は歓迎します。また、提案をお勧めします。 そしていつものように、お時間をいただきありがとうございます。

14 design-patterns  mvc  mvvm  mvp 

私はクリーンアーキテクチャに入り、AndroidレベルをMVCからMVPに上げ、Dagger 2でのDI、RxJava 2での反応性、そしてもちろんJava 8を紹介します。 でMVPクリーンなアーキテクチャが存在し、エンティティ間の層（データストア内）とプレゼンターそれらにアクセスする必要があります。このレイヤーが「ユースケース」です。使用例は、理想的には1つのエンティティに1つの操作を実装するインターフェースです。 また、Clear Architectureは「悲鳴を上げている」ことも知っています。そのプロジェクトの意味では、クラスの数が多いため、非常に読みやすくなっています。 今、私のプロジェクトでは、6つの異なるエンティティのようなものがあり、もちろん、各エンティティリポジトリには、それらにアクセスするための少なくとも4つのメソッド（通常はget、add、delete、update）があります。つまり、6 * 4 = 24です。 Clean Architectureのこれまでに理解できたとしたら、24のUseCaseがあります。 MVCの6つのコントローラーと比較すると、これは多くのクラスです。 本当に24のユースケースを作らなければならないのですか？ 私はすでにそれを成功裏に使っている誰かによる説明を本当に感謝します。 ありがとう、ジャック

14 java  android  use-case  mvp 

私の考えを追加するために、質問は自明です： 私が読んだ限り、Clean archのプレゼンテーション層は、MVPのMVと同じ責任を負っています。 あるパターンを他のパターンではなく選択する方法は？

13 architecture  mvp 

私が読んだ本のデザインパターンについてのページを、そしてあなたのコードを書くときに、どのようにそれらを扱う必要があります。私の理解から、リンクのタイトルは次のように述べています： パターンはビルディングブロックではありません。 私が正しく理解していれば、これは意味があるまでデザインパターンを使用しないことを意味しますよね？戦略パターンを使用するつもりだと言って始めないでください。コードを書くまで待ってください。戦略パターンを使用することが設計に意味がある場合は、それを使用してください。 GUIアプリケーションを作成するとき、MCV / MVPパターンを同じように扱いますか？それぞれのリンクから、それは建築パターンであると述べています。 GUIアプリケーションを作成し、MCV / MVPパターンを使用していなくても、コードがクリーンで、読みやすく、保守可能である場合、MCV / MVPパターンを使用しなかったのは、コードのにおい/悪い設計であると想定します。 ？

9 design-patterns  mvc  mvp 

開発中のAndroidアプリでMVPパターンを使用しています。 基本的に4つの要素があります。 新しいユーザーを追加できるAddUserView： AddUserPresenter UserInfo（pojo） UserInfoManager（ビジネスロジックとストレージマネージャー） 私の質問は： AddUserViewの「追加」ボタンを押すと、テキストビューのコンテンツが取得され、新しいUserInfoがインスタンス化されて、Presenterに渡されます。または、AddUserViewは単にtextViewsのコンテンツを取得してAddUserPresenterに渡す必要があります。これにより、実際にはUserInfoがインスタンス化され、UserInfoManagerに渡されますか？

9 java  architecture  android  mvp 

私はMVPについて、特にコントローラーの監督について読んでいます。ビューをモデルとどのようにやり取りするかは、頭を抱え込むのが難しい点の1つです。 プレゼンターがモデルを更新する必要があり、ビューがモデルから読み取ることは私の理解でした。プレゼンターは、インターフェイスを介してビューを更新することもできます。これに関するマーティンファウラーの記事は、まさにそれを示しているようです（http://martinfowler.com/eaaDev/SupervisingPresenter.html）。 ただし、他の記事/ブログは、モデルを直接更新するビューを示しています（https://blogs.msdn.microsoft.com/erwinvandervalk/2009/08/14/the-difference-between-model-view-viewmodel-and-other-分離表示パターン/）。 これらは単なるパターンであることを知っているので、さまざまな実装がありますが、モデルを更新するビューは、必要以上に多くのことを行っているようです。 たとえば、名前と電話番号を含む人物クラスがあったとします。ビューには、この名前と番号、および個人の名前と番号を変更するための送信ボタンを表示できます。送信ボタンをクリックすると、ビューではなくプレゼンターで更新が処理されると思います。ただし、私が参照した記事は、ビューがモデルを直接更新できることを提案しています。 それで、ビューはモデルを更新する必要がありますか？それとも、プレゼンターだけが処理する必要がありますか？ 編集： MSDN記事のコード： public class PersonalDataView : UserControl, IPersonalDataView { protected TextBox _firstNameTextBox; public void SetPersonalData(PersonalData data) { _firstNameTextBox.Value = data.FirstName; } public void UpdatePersonalData(PersonalData data) { data.FirstName = _firstNameTextBox.Value; } }

8 design  design-patterns  object-oriented-design  mvp 

MFCプロジェクトでThe Humble Dialog Boxペーパー（pdf）に記載されているモデルビュープレゼンター（MVP）パターンを使用しています。問題はほとんどのGUIツールキットと同じだと思います。 私を悩ませているのは、プレゼンターだけでなく、プレゼンターが必要とするサービスも作成している具体的なビュー（つまり、ダイアログクラス）です。それは正常ですか？ビューがプレゼンターが必要とするサービスを知る必要があるのはなぜですか？私が考えているのは、プレゼンターをダイアログクラスに依存的に挿入する必要があるということです。 アプリケーションのメインコントロールは、CWinAppから派生したクラスです。では、このクラスでサービスとプレゼンターを作成してから、ダイアログクラスに挿入する必要がありますか？ ただし、プレゼンターがコンストラクターでビュークラスへの参照を必要とする場合、ダイアログクラスにプレゼンターを依存性注入するにはどうすればよいですか？ MyPresenter(IView *view, MyService *service); また、メインウィンドウがポップアップウィンドウからスポーンした場合、そのウィンドウプレゼンターとサービスの詳細はどこに構築する必要がありますか？ これはC ++なので、どんな種類のDIフレームワークにも興味があるとは思いません。 更新 私が持っていた1つのアイデアは、nullビューでプレゼンターを作成し、コンストラクターがプレゼンターをダイアログクラスに挿入し、ダイアログクラスのコンストラクターでSetView(IView *view)プレゼンターのメソッドを呼び出すthis場所thisがダイアログクラスになる場所（IViewから派生）でした。 ）。そう： MyApp::Start() { SomeService *service = new SomeService(); MyPresenter *presenter = new MyPresenter(null, service); MyDialog *dialog = new MyDialog(presenter); ... } MyDialog::MyDialog(MyPresenter *presenter): presenter_(presenter) { presenter_->SetView(this); } 少しぎこちないように見えますが、サービスの構築をDialogクラスから除外しています。空のビューは少し危険なようです。代わりの方法は、空のメソッド本体を持つNullViewクラスを実際に作成し、それをプレゼンターコンストラクターに渡すことです。

8 dependency-injection  mvp  presentation-model