3

私たちは、 WPF/Prism (複合アプリケーション ライブラリ)を使用して、社内のシック クライアント アプリケーションの次のバージョンを構築していました。クライアントとの取引がほぼ完了したため、チームは新しい管理下に置かれ、その後まもなく:

  1. その後、物事をシンプルに保つために Prism フレームワークを削除するように指示されました。これには、いかなる種類の制御の反転も使用しないことが含まれます。

  2. MVVM などを使用せずに WPF アプリケーションを構築するように指示されました。従来の WinForm アプリケーションと同様です。アイデアは、開発者が Visual Studio のデザイナー ビューでコントロールを見た場合、ビュー モデル (または同様のもの) をトラバースすることなく、コントロールをクリックして、それが何をしているかを正確に確認できるようにすることです。

  3. ここでは、1 つのプライマリ ウィンドウを使用して WPF アプリケーションを構築し、フレーム コントロールを使用してコンテンツを格納し、フレームの外側でメニュー項目用のリボンを使用する作業を行いました。フレーム コントロールを使用するように提供された理由:

    を。フレームにページ(ユーザー コントロールではない) を含むビューを表示し、そのページをフレームに読み込みます。

    b. フレームに新しいビューを表示する場合、現在のビュー (ページ) は閉じられて破棄され、新しいビュー (ページ) がフレームに配置されます。

    c. 開発者がページをデザイン ビューで見ると、任意のコントロールをクリックして、何が行われているかを正確に確認できます。

上記の 1 と 2 の制限があるため、次のようなアプリケーションを構築する別の方法を紹介したいと思います。

  1. 「フレーム方法論」（上記の項目 3）を使用する代わりに提示できますが、それでも同じタイプの機能を提供します。

  2. MVVM を使用しません (上記の #1 と #2 を参照)。

私たちが与えられた方向性を踏まえて、私たちが提示できる代替案について何か提案はありますか? 回答は専門的なレベルにとどめていただきたいと思います。よろしくお願いいたします。

4

4 に答える 4

6

個人的には、Martin Fowler のプレゼンテーション モデルを使用することを主張したいと思います。（それは冗談です、ところで...）

基本的に、「WPF を使用しますが、WPF を使用可能にする機能は使用しないでください」という制限が与えられています。あなたの要件は、MVVM のようなパターンの利点を合理的に説明する方がはるかに良いように思えます。

奇妙な要件は、実際には次のようになります。

アイデアは、開発者が Visual Studio のデザイナー ビューでコントロールを見た場合、コントロールをクリックして、そのコントロールが何をしているかを正確に確認できるようにすることです。

それが主な問題であり、MVVM やその他の同様のパターンを回避している理由である場合は、時間をかけて経営陣を教育することを真剣に考えます。コマンドをイベントの代わりに名前で見ること (これはデザイナーで表示されるものです) は、それほど難しいことではありません。

ただし、大規模なアプリケーションでは、関心の分離が重要です。適切に設計された Windows フォーム アプリケーションであっても、問題を明確に分離する必要があります。イベント アプローチを使用して大規模でクリーンなアプリケーションを開発しようとすると、イベント ハンドラーが作成されますが、これらのイベント ハンドラーは最終的にすべての作業を別のコンポーネントに委任する必要があります。

これは、MVVM で得られるものに加えて、理解とメンテナンスの観点から、実際には余分なレベルの作業を追加することになります。MVVM を使用すると、非常に発見しやすい ViewModel だけを見ることができます。

ところで - UserControl の代わりに Page を使用するための「理論的根拠」は意味がありません。UserControls で記述しているのとまったく同じことができます... Frame と Page を使用する唯一の理由は、ナビゲーションを利用したい場合です。その場合、古いページを直接破棄することはできません (またはそれらは常に再生されます）。また、ナビゲーション ツールはおそらくリボンでは使用されません。2 つの概念モデルはまったく異なります。

于 2010-03-17T01:01:40.293 に答える
2

あなたのプロジェクトに当てはまるかもしれない MVVM に対する批判があります。ただし、プログラミング方法論を不合理に指示することは、常に災害のレシピです。

フレームワークを用意し、レイヤーの構築と分離に時間を費やす理由の 1 つは、「ビジュアル スタジオのボタンをクリックするだけで実行中のコードを確認できる」場合に常に発生するコーディングの混乱を避けるためです。

MVVM に似たものがなければ、要求されたことを達成する方法はないかもしれません。アーキテクチャを持つものは、あまりにも似ているとラベル付けされる可能性があるからです。

ただし、現在 Emesary と呼ばれる単純なオブジェクト間配管を提供するシステムを長年使用しており、私のC# .NET Emesary ウォークスルーを読むことをお勧めします。

しかし、基本的には、ボタンを次のように実装できます。

    private void addButton_Click(object sender, RoutedEventArgs e)
    {
        GlobalTransmitter.NotifyAll(new Notification(NotificationType.CreateRecipe));
    }

これはあなたの問題に対する答えかもしれません。誇大宣伝されていない、小さくてとてもシンプルですが、うまく機能します。

ウィンドウ、リボン バーのユーザー コントロール (ユーザー コントロールにはリストビューが含まれます)、およびフレーム パーツの別のユーザー コントロールを使用して、2 番目の質問に対する解決策を達成しました。この 2 番目のユーザー コントロールは、非常に単純なビュー クラスを使用して他のユーザー コントロールを使用して構築されています。すべてのビューとコントロールは、Emesary を使用して接続されています。

于 2010-03-17T01:58:04.657 に答える
1

学校のプロジェクトとして、複数の人が同時に使用できるWPFクライアントを開発する必要がありました。そして、私はページを使用しました。私の評決：多大な労力を節約し、代わりにUserControlsを使用してください。

ページナビゲーター（スクロールに使用します）がバグアウトして多くの問題を引き起こす傾向がある場合があります。多分それは私のくだらないコーディングでしたが、誰が知っていますか？

言わざるを得ないのですが、「ページ」と呼ばれるコントロールはやや誤解を招きます…「エウレカ！」に行きました。私がそれらを見つけたとき、そしてその後それらに誓った。

私は＃2に完全に同意します（MSビッグスは注意してください！）。コントロールをダブルクリックして、そのコマンド（またはコマンドが不足している場合はイベント）に直接移動できると便利です。ただし、それまでは、ViewsとViewModelsを別々のフォルダーに整理してください。

デュアルスクリーン（または非常に広いスクリーン）を使用すると、プロジェクトでVSの2つのインスタンスを開くことができます。1つはビューに焦点を合わせ、もう1つはViewModelに焦点を合わせます（私の個人的な選択はビューにExpression Blendを使用することでした）。

それほど大きなアプリケーションではありませんが、プロジェクトを適切なMVVM（つまり、すべてのUI要素のViewModel、RelayCommands、Mediator）に数日で変換できたので、一度理解すれば、実装するのはそれほど複雑ではありません。さらに、MVVMを半分の難易​​度と2倍の強力にするツール（JoshSmithのRelayCommandやMarlonGrechのMediatorなど-完全に無料）があります。

MVVMなしでWPFを使用することは、フォークなしでご飯を食べようとするようなものです。WPFが提供するものを利用しない場合は、WinFormsを使用する方がよいでしょう。私の2セント。

于 2010-05-18T16:51:18.010 に答える
0

あなたの管理は完全に間違っていると言えたらいいのですが..しかし、それは最も正確な真実ではないので、私はそれを言うことはできません. あなたが説明した変更の主な理由は、新しいマネージャーが MVVM が UI 開発の新しい救世主であるという概念に満足していないか、または教育を受けた洗練された開発者と安価な開発者のコ​​ストが関係している可能性があるためだと思います。これは、リーン開発として広く知られている概念です。

だから、私がこれまでに書いたすべてを「あなたが求めたものではない」の下に置いて、ここに私が提案するものがあります: オブジェクト指向の純粋なアプローチを引き続き使用できます。したがって、すべてのオブジェクトはウィンドウ派生オブジェクトになります。そのようにすると、SOC で緩みますが、それでも OOP/OOD になります。

しかし、LOL、次のフェーズでは、同じデータを中継する多くの派生ウィンドウで同じコードを繰り返さないように、ビューからモデルを分離することになります...そのため、管理者は MVC/MVP を優れたソリューションとして承認します..そしてWPFが必要な場合、MVVMまでの距離は少し短いです。

結論: プロジェクトが非常に短い場合を除き、MVVM を使用する方がよい理由をマネージャーに教える必要があります。

于 2012-06-12T16:33:04.877 に答える