2

WPF のビュー モデル指向の方法では、UI でビジネス オブジェクトを使用したくなるだけです。これに関する問題を見たことがありますか？なぜ、またはなぜあなたはこれをしないのですか？

4

5 に答える 5

6

Microsoft の製品チームからのガイダンス (たとえば、Blend チームが使用しているもの) は、一般的な MVC パターンの変形である Model-View-ViewModel アーキテクチャです。良い出発点はhttp://blogs.msdn.com/johngossman/archive/2005/10/08/478683.aspxです。このトピックに関する WPF 博士による優れた記事もあります。

基本的に、彼らは、ObservableCollection などのバインドしやすいビジネス オブジェクトを使用する ViewModel レイヤーを作成することを提唱しています。

また、最終的に Silverlight 2 に移行する可能性がある場合は、ビジネス オブジェクトを UI レイヤーから除外して、UI テクノロジを交換できるようにすることをお勧めします (WPF と Silverlight がソース コード互換になるまで)。

于 2008-11-03T17:48:05.293 に答える
2

ビジネス オブジェクトを表示するだけであれば、UI にビジネス オブジェクトを配置しても問題はありません。つまり、プロパティを変更したり、削除したり、新しいプロパティを作成したりする場合は、コントローラー、プレゼンターなどにメッセージを送信してそれを行う必要があります。結果はビューで更新されます。

ビューでの表示方法に影響を与えるために、オブジェクトのメソッド (またはオブジェクトのその他のメソッドやプロパティ) を使用することは、すべきではありません。オブジェクトのビューを表すには s をToString使用する必要があります。DataTemplateより複雑な表現が必要な場合は、 を使用しIValueConverterてオブジェクトを視覚的な表現に変更できます。

于 2008-11-03T17:47:27.667 に答える
2

私はそれを別の光で見ていると思います。必要な UI プレゼンテーション (つまり、Web、WPF、WinForms) を使用できるように、できるだけ UI を使わないようにしています。プレゼンテーション層のビジネス ロジックが多いほど、後で別の UI に移行する場合に、より多くの書き直しが必要になる場合があります。

于 2008-11-03T17:13:17.393 に答える
1

アプリケーションアーキテクチャまたはコンポーネントとオブジェクトの再利用を計画している方法に応じて、ユーザーインターフェイス（この場合はWPF）からある程度の独立性を選択できます。

これが私の経験のサンプルです：

私は、ビジネスレイヤーがすでに定義されている比較的小さなプロジェクトで、WPFを少し使用しましたが、ユーザーインターフェイスを作成する必要がありました。もちろん、インターフェースはそれが動作する独自のルールとオブジェクトを定義していました。アプリケーションはUX専用に定義されていたため、主に拡張することによって DependencyObject（主にData Binding目的のために）独自の特定のオブジェクトを作成することを選択しました。

一部の人々は、依存関係オブジェクトはシリアル化できないため（実際には、XAMLに対して）、WPF（ System.Windows名前空間）への依存関係をもたらすため、依存関係オブジェクトを使用しても問題ないと主張する場合があります。また、 添付プロパティ や依存関係プロパティDependencyObjectsなどの他のオプションもサポートします。他の人は、たとえば それが理にかなっている場合に使用したいと思うかもしれませんし、他の人はこれらのパターンのすべてがUI以外のレイヤーに属していないと言うかもしれません。（詳細を知りたい場合は、MSDNライブラリにパフォーマンスとユーザーインターフェイスのベストプラクティスを含む、いくつかの優れたWPFデータバインディングの記事があります）INotifyPropertyChanged

System.Windowsたとえば、System.ComponentModel私の意見では、これらの重要なパターンをすべてWPFだけでなく、.NET Framework）。

もちろん、これはほんの始まりに過ぎず、私たちの多くは、物事が最終的に正しい方向に進化することを知っています。（トピックから外れるリスクがあります。たとえば、silverlight 2.0フレームワークを取り上げます。これは急いでリリースされたもので、WPFモデルのオブジェクトの一部が欠落しており、一部は自然な場所にありません。）

結局のところ、すべてはあなた、あなたのプログラミングスタイル、あなたのアーキテクチャ上の決定、そしてあなたのテクノロジーに関する知識に依存します。

本よりもある意味でそれを行う方が自然だと思われる場合は、決定を下す前に考えwhy you shouldてください。why should you not

于 2008-11-03T18:45:30.967 に答える
1

WPF の第一人者ではないので、よくわかりませんが、M、V、および C を分離する通常の理由は、コントローラーをビューから独立してテストできるようにするためです。

もちろん、あなたを止めるものは何もありませんが、それが分離されていれば、はるかにテスト可能 (つまり、単体テスト) になるはずです。通常、MS が推進する MVP パターンは、プレゼンター (つまり、WPF フォーム) をより細かく制御できるように調整されており、それも問題ありません。

于 2008-11-03T17:10:44.387 に答える