1

すべてのもののコンテナーとして、アプリケーションのルート AppViewModel であるルート AppView を作成しました。アプリケーション ビュー内には、各タブが独自のタスクを実行する TabControl があります。データのインポート用の 1 つのタブ、発行用の 1 つのタブ、管理用の 1 つのタブなど:

App_View[Model] // root
{ 
   TabTask1_View[Model], TabTask2_View[Model], TabTask3_View[Model] // tab items
}

1) MVVM では、ビューとビューモデル全体をメインの application-view と application-model-view にグループ化するのは標準ですか?

2) MVVM では、すべてのビューと vm に対してモデルを実装する必要がありますか? それとも、モデル全体を 1 つまたは 2 つのクラス ファイルに実装し、それらの間でモデルを共有するのは標準ですか? 個人的には、コード内のどこでも使用でき、特定のビューに制限されないクラス「学生」のように、モデル部分は特定のビューに固有のものではないと思います。これに基づいて、モデルが一般的で共有されている場合、それでもクラス + 'モデル' という命名規則に従うのがよいでしょうか? StudentModelが好きですか？私が言ったように、一般または共有クラス名の後に「モデル」を追加することは役に立ちますか/必要ですか?

3) WPF では、ビューを実装する最良の方法は何ですか? 私は非常に簡単に制限なく編集および設計したいと考えており、将来のニーズをカバーするのに十分な標準である必要があります。使用するものは、Window、Page、UserControl、および DataTemplate の 4 つです。あなたが選ぶ最良の選択肢はどれですか？ユーザーコントロールまたはページ?

4) WPF では、MVVM アプローチに基づいて、実行時に tabItem 内に UserControl/Page(View) を動的にロードするにはどうすればよいですか?

4

3 に答える 3

2

あなたはだましています。それは4つの質問です！

1)

ビューとビューモデルをグループ化する方法に関しては、ビューとビューモデルを同じ名前空間/フォルダーに配置し、機能に基づいて別のフォルダーに分ける人を見てきました。あなたにとって最良の選択肢は、あなた/あなたのチームに合ったものです. 「正しい」方法はありません。

2)

乾いた状態に保ちます-同じことを繰り返さないでください. コードを再利用することは非常に賢明です。共通のクラスがある場合は、それらを共通に保ちます。命名に関しては、クラスの名前はそれが何をするかを説明するのに役立つはずです: クラス NavigationService、NavigationMenuItem、および NavigationMenuView が何をしたかを理解できると確信しており、おそらくどのように良いメンタル モデルをまとめることができるでしょう。彼らは関係しています。したがって、クラス BlahViewModel または BlahModel に名前を付けることが役立つ場合は、そうしてください。

3) ビューの実装:

Window は常に独立して表示されます。ページは、ナビゲーション アプリケーション (通常、Internet Explorer などの [戻る] ボタンと [進む] ボタン) で使用することを目的としています。ページは、NavigationWindow または Frame でホストする必要があります。コンテンツの動的な追加/削除、ItemsControls (TabControl など) へのコンテンツの追加を検討している場合は、ユーザー コントロールを作成する必要があります。ユーザー コントロールを Page および Window オブジェクト、他のコントロールなどに配置することができ、WPF 開発者にとって実際に役立っています。

4)

ここにはいくつかのオプションがあります。

1)手っ取り早い方法は、タイプ X の ViewModel が与えられると、ViewModel をロードしてデータ コンテキストに適用する DataTemplate を作成することです。これにより、ViewModel をコントロールに直接挿入し、正しいビューをレンダリングできます。

例：

View.xaml

<ContentControl Content="{Binding Error, Mode=OneWay}" />

ビューモデル:

        private void ReceiveError(ErrorViewModel errorModel)
        {
            //if (errorModel.AcceptCommand==null || errorModel.AcceptCommand is NoOpCommand)
            errorModel.AcceptCommand = new DelegateCommand(ClearError);
            Error = errorModel;
        }
public ErrorViewModel Error
        {
            get { return _error; }
            set
            {
                _error = value;


                _propertyChangedHelper.NotifyPropertyChanged(this, () => Error);
            }
        }

Styles.Xaml (ResourceDictionary)

<DataTemplate DataType="{x:Type vm:ErrorViewModel}">

        <DataTemplate.Resources>
            <conv:CustomisableBooleanToVisibilityConverter x:Key="VisibilityConverter" TrueValue="Visible" FalseValue="Collapsed" />
        </DataTemplate.Resources>
        <Popup AllowsTransparency="True" PopupAnimation="Fade" Placement="Center"  StaysOpen="True"
               PlacementTarget="{Binding Mode=OneWay, RelativeSource={RelativeSource FindAncestor, AncestorType={x:Type v:ModuleView}}}"
               IsOpen="True" Width="400" SnapsToDevicePixels="True"/>

ビューモデルをコンテンツ コントロールに直接挿入し、ビューモデルの型にバインドされたデータ テンプレートを使用してそのビューを見つけていることがわかります。

2)

DataTemplateSelector を使用することをお勧めします。これにより、基本的に、コントロールで使用できるテンプレートを指定し、コーディングしたロジックを使用して、使用するデータ テンプレートを決定できます。この例はここにあります。

3)

UI コントロールを抽象化するフレームワークを使用します。Microsoft には、Prism と呼ばれるこれを行うフレームワーク (無料) があります。基本的に、ユーザー コントロールを TabControl、ItemsControl などに直接追加する代わりに、コントロールを名前付きの "Region" に追加します。この領域は基になるコントロールにマップされ、ユーザーが要求したときにその UserContorl が追加/削除される方法を管理するためにアダプターが配置されます。この詳細については、こちらを参照してください。ただし、Prism はアプリケーション フレームワークであるため、これを実装するのに 3 時間もかからないことに注意してください。

于 2013-06-21T09:24:14.497 に答える
1

ポイント 1:

場合によります。私の知る限り、広く使用されているアプローチは 2 つあります。最初は、あなたが言ったようWindowに、直接の依存関係で同じを構成するすべての VM をグループ化して、実際のプログラム構造を示すクラス構造を形成します。2 つ目は、EventAggregator(Prism) / Messenger(MVVM Light) を使用して、直接的な依存関係ではなく VM を緩やかにリンクする場合です。

現在、両方のアプローチに利点があります

  • 最初のものでは、VM の依存関係が明確に示されているため、プログラム構造を特定するのは非常に簡単ですが、2 番目のアプローチからはそれほど明確には見えません。
  • 2 番目のアプローチは、VM の単体テスト時に、依存するすべての VM をモックまたは回避する必要がない場合に非常に役立ちます。また、プロジェクト構造を変更するときのコードのリファクタリングにも役立ちます (「プラグイン」クラスを考えてください)。

ああ、これら ^^ 決して排他的ではありません。これらをうまく混ぜ合わせることができます。

ポイント 2:

モデルには、View と VM の関係のような、View / VM との推奨される 1 <-> 1 関係はありません。モデルはビジネス ロジックを保持するだけです。モデルをまったく保持しないアプリが時々あります。アプリケーション全体で使用されるモデルは 1 つだけです (バックエンドが C++ ライブラリであり、C++/CLI モジュールとインターフェイスするだけの場合)。はい、Modelクラス名に「Model」を追加する命名規則を維持します

ポイント3

それらのすべてはどうですか？該当する場合はそれらを使用してください。どちらかを部分的に優先しないでください。View がそれ自体で VM を含む View である他の複数のセクションを構成する場合、DataTemplateData a を使用しUserControlます。あなたのアプリはほとんど常にウィンドウを使用しており、Pageナビゲーション ベースのアプリに役立つと思います。は、私Pageが少なくとも使用したものだと思います。

ポイント4

チュートリアルの質問です。たくさんの例を取り上げ、それがどのように実装されているかを見て、それを推論し、アプローチを選択してください。VS2010を使用している場合は、MVVMが同梱されています（これは素晴らしいことです。2つの方法はありません。まだVS2012用に更新されていない場合は、これが更新されることを本当に願っています）。VS2012 については、概念を示すTwo Views MVVM CodeProjectをチェックしてItemsControlください。選択したものに適用できます。

最後に、少なくとも起動するときは、 MVVMヘルパー ライブラリを使用して開始してください。私はMVVM Light <-そのリンクには、ライブラリの作成者によるいくつかの使用法を示すいくつかのビデオがあり、SOに関する広範なヘルプを見つけることができます。自分でやりたい場合は、そこから基本を学び、自分で実装してください。初日から大道を歩むと、学習曲線がはるかに長くなります（私の意見です）

于 2013-06-21T09:12:26.980 に答える