問題タブ [mvp]

MVC や MVP デザイン パターンを使用する場合はビジネス ロジックがモデル内に存在する必要がありますが、サービス指向アーキテクチャではサービスの背後に隠されている必要があると思います。

ソフトウェア システムは、サービス指向アーキテクチャ内で MVC または MVP 設計パターンを使用できますか? もしそうなら、モデルはどこに座っていますか?

今では MVP パターンを完全に理解していますが、ビューとプレゼンターがインスタンス化されている場所を確認するのにまだ苦労しています。ビューでプレゼンターが新しくなる例をいくつか見ましたが、これは正しいですか。ビューとプレゼンター間の通信に関する Jeremy Miller のブログ投稿を読んだ後、プレゼンターをビューにアタッチする関数をプレゼンターに追加しました。

私の質問は次のとおりです。ビューとプレゼンターはどこで作成する必要がありますか? また、winforms と webforms のどこにあります。

私は TDD の初心者ですが、MVP パターンを使用して素敵な小さなサンプル アプリを作成することに成功しました。私の現在のソリューションの主な問題は、UI スレッドをブロックしていることです。そのため、SynchronizationContext.Current を使用するようにプレゼンターをセットアップしようとしましたが、テストを実行すると SynchronizationContext.Current が null になります。

スレッド化前のプレゼンター

ねじ切り前のテスト

SynchronizationContext Threading を Presenter に追加した後、StatusMessage の Fake View に AutoResetEvent を設定しようとしましたが、テストを実行すると SynchronizationContext.Current が null になります。新しいプレゼンターで使用しているスレッド モデルが完全ではないことはわかっていますが、これはマルチスレッドをテストするための適切な手法ですか? SynchronizationContext.Current が null になるのはなぜですか? 代わりに何をすべきですか？

スレッド化後のプレゼンター

ねじ込み後のテスト

フェイクビュー

MVP パターンに関する多くの記事を読みました。複雑すぎると言う人もいれば、時代遅れだと言う人もいます。しかし、私にとっては、UI への単体テスト アクセスを提供するのに最適な方法のように思えます。これは、私が達成しようとしていることです。

MVP を使用したことがありますか。使用している場合はどう思いますか?

ドメイン駆動設計では、ファクトリを使用してドメイン レイヤーにドメイン オブジェクトを作成することをお勧めします (直接コンストラクターまたは IoC を使用するのではなく)。

しかし、プレゼンター レイヤーでドメイン オブジェクト ファクトリを使用する場合はどうでしょうか。たとえば、プレゼンターから取得したユーザー入力からドメイン オブジェクトを作成していたとします。

以下に例を示します。10 進数の設定を持つ構成ドメイン オブジェクトがあるとします。

パブリック クラスの構成: PersistantObject {

}

このオブジェクトをプレゼンター レイヤーではなくドメイン レイヤーで作成するには、これらの各 10 進数値を関数パラメーターとして渡す必要があります。扱いにくい関数定義と呼び出しを作成します。

つまり、ConfigurationService.CreateConfiguration(温度、...(x20)、重力);

おそらくより良い解決策は、構成オブジェクトをプレゼンター レイヤーに作成し、構成オブジェクトのすべての値をユーザー入力から直接割り当てて、長い関数呼び出しをスキップすることです。

構成 config = ConfigurationFactory.CreateNewConfiguration();

config.temperature = 温度;

..(x20).. = ...;

config.gravity = 重力;

ConfigurationService.SaveNewConfiguration(config);

しかし、このアプローチが間違っているかどうか疑問に思っています。なぜですか? これらのアプローチの両方が間違っている場合、ユーザー入力から長いオブジェクトを作成するための最良のアプローチは何ですか?またその理由は何ですか?

ありがとう！

ユーザーコントロールに関連するため、MVP のいくつかについて頭を悩ませようとして楽しんでいます。私は.NET WinForms（またはそれに近いもの）とSupervising Controllerパターンを使用しています（まあ、私はそうだと思います:)。

ユーザー コントロールは、それ自体が MVP アプリケーションの一部です (そのビューであり、関連付けられたプレゼンターなどがあります)。プレゼンターは常に最初に開始され、モデル、ビューの順に開始されます。ビューはその UI を構築します。その一部は、ビューである新しい UC になります。

（フォーム）PresenterはUC Presenterについて知る必要がありますが、Viewがどのように構成されているかについては何も知らないと思います。たとえば、フォーム プレゼンターは、UC がフォームの Controls コレクションの一部であることを知りません。

さらに、設計経験は変更されるべきではありません。ビュー（フォーム）のIOW開発者は、ツールボックスからユーザーコントロールを選択してフォームにドロップできるはずです。

それでは、私の質問に進みます。まず、上記の私の仮定は正しいですか？やや見当違い？めちゃめちゃ？WTFあなたは考えていますか？

第 2 に、フォーム ビューで UC ビューを呼び出し、フォーム プレゼンターで UC プレゼンターを呼び出して、UC ビューにそのプレゼンターが何であるかを伝える何らかのメカニズムを持たせることは正しいですか (十分ですか?)。これは私の「Presenter first」ルールに違反していますが、それ以外の方法がわかりません。

その他の考え、提案、コメントは喜んで受け入れます。

-- nwahmaet

Autofac を既存の ASP.NET Web アプリケーションに統合しようとしています。

ページは MVP パターンに従います。各ページはビューを実装し、機能をプレゼンターに委任します。ビューは、コンストラクターを介してプレゼンターに注入されます。

プレゼンターとビューを登録でき、ページは正常に読み込まれましたが、ポストバックが発生すると、ビューのユーザー コントロールが null になります。Autofac は、インスタンスに実際の Page インスタンスを与えるのではなく、プレゼンターに与える Page の新しいインスタンスを作成するようです。Page インスタンスを Autofac に登録する方法はありますか?

ASP.NET と MVP で Autofac を使用している人はいますか?

ありがとう！

Model-View-Presenter (または MVC や MV-VM、または使用しているバリアント) で遅い操作をどのように処理しますか?

WinForms、SWT/JFace、または使用しているデスクトップ フレームワークでの操作が遅い場合は、バックグラウンド スレッドで実行して、アプリケーションが完全にロックされないようにする必要があります。これはどこで処理するのですか？

いくつかの解決策を見ることができますが、それらのいずれにも完全に満足しているわけではありません:

1. ビューの呼び出しで、常にバックグラウンド スレッドでプレゼンターを呼び出すようにします。つまり、ビューは、プレゼンターからのすべての呼び出しがおそらくバックグラウンド スレッドから来ることを処理する必要があります。

2. メイン スレッドでビューにプレゼンターを呼び出させます。バックグラウンドで実行できるように、遅い操作を実行する場合、プレゼンターはビューにコールバックする必要があります。

普段何をしていますか？

編集:この記事を見ました: http://www.codeproject.com/KB/threads/ThreadedExecuter.aspx。これは基本的に 2 の実装です。このようなことを試した人はいますか?

アプリケーション全体で再利用したいユーザーコントロールがあるが、プレゼンターも必要とするページやその他のコントロールがある状況に興味があります。

だから私はアップロードビューとコントロールを持っていると言う

しかし、私はページビューも持っています

アップロードコントロールはExcelProcessorページにあるため、ユーザーはファイルをアップロードして、Excel処理のビジネスロジックに渡すことができます。

だから私にはプレゼンターがいます

ExcelProcessorViewで、次のようにプレゼンターを接続します。

これはMVPパターンの正しい使用法ですか？

私は、1つのプレゼンター関係に対する多くのビューを処理するためのベストプラクティスを理解しようとしています。MVPは、このように多対1の関係を持つことができますか。別の質問として、MVPパターンが、プレゼンターが多く、ビューが多い（またはプレゼンターが1人だけである）状況を処理できるかどうか、または処理できるかどうかも知りたいですか？

私のMVPの一般的な解釈に問題がある場合は、ぜひ先に進んでそれを指摘してください。

読んでくれてありがとう！

モデル ビュー プレゼンター パターンの独自のコピーを (Web クライアント ソフトウェア ファクトリに沿って) 実装したので、多くの問題を抱えていた WCSF の ObjectBuilder に縛られる代わりに、独自の DI フレームワークを活用できます。私はそれを行うためのいくつかの方法を思いつきましたが、特に私を幸せにする方法はありません. 他の誰かが他のアイデアを持っているかどうか知りたかった.

解決策 #1a

HttpModule を使用して context.PreRequestHandlerExecute をインターセプトし、ObjectFactory.BuildUp(HttpContext.Current.Handler) を呼び出します。

解決策 #1b

HttpModule を使用する代わりに、ページの読み込み時に buildup を呼び出す

解決策 #1c

Property を介してプレゼンターにアクセスし、必要に応じて Getter を BuildUp できるようにします。

解決策 2

解決策 2b

編集：ソリューション1c、2bを追加