web-dev-qa-db-ja.com

WPFのMVVMのプロジェクト構造

WPFでMVVMを使用する場合、最終的にどのプロジェクト構造になりますか？

今見たチュートリアルでは、通常、Model、ModelView、Viewというフォルダーがあります。

モデルでは、たとえばデータやロジックをキャプチャするPersonなどのクラスを配置します。

ModelViewでは、Modelで定義されたクラスをインスタンス化します。ビューには.xamlファイルが含まれています。

編集：元の投稿を編集して、プロジェクト構造の例を送信します。これに関連する質問があります。これらを整理する方法：App.config App.xaml MainWindow.xaml

それらを今のように外に置いておくべきですか、それとも何らかのフォルダーに入れるべきですか？

enter image description here

c#wpfxamlmvvm
55
user2381422

通常または共通のフォルダーレイアウトについて説明しました。経験から、あなたが言及した典型的なPersonクラスなどのモデルデータタイプ用に別のフォルダー（または大規模アプリケーションのプロジェクト）を追加することを好みます。これを行う理由は、これが最大のプロジェクトの1つになることが多いためです。また、次のサブフォルダーに分割しました。

DataTypes
    Collections
    Enums
    Interfaces

また、アプリケーションConverterクラス、拡張メソッドクラス、ユーティリティ（またはサービス）クラス用に個別のフォルダー（または大規模アプリケーションのプロジェクト）があります。最後に、アプリケーションのフォルダー構造にほぼ一致するテストプロジェクトがあります。全体として、これはおおよそ私のフォルダーの外観です：

Solution

    Third Party Libraries <<< (Solution Folder)

    StartUp Project
        Images
        Resources

    Converters

    DataTypes
        Collections
        Enums
        Interfaces <<< (For Data Type classes)

    Extensions

    Models
        Data Controllers
        Data Providers
        Interfaces <<< (For swapping Model classes out in test projects)

    Utilities (Or Services)
        Interfaces <<< (For swapping Utilities classes out in test projects)

    View Models
        Commands

    Views
        Attached Properties
        Controls

更新>>>

フォルダーのようなプロジェクトは、分離レベルを提供するだけです。また、アプリケーションの名前空間をマップするのにも役立ちます。たとえば、Collectionsフォルダー/プロジェクトのコードクラスは、ApplicationName.DataTypes.Collections名前空間にあります。 Data Providersフォルダー/プロジェクト内のクラスには、ApplicationName.Models.DataProviders名前空間があります。

さらに、大規模なアプリケーションでは、プロジェクト名はこの階層内の場所に由来します。たとえば、DataTypesプロジェクトは実際にApplicationName.DataTypesと呼ばれ、ModelsプロジェクトはApplicationName.Modelsと呼ばれます。 CollectionsとDataProvidersの部分は、2番目のレベルを過ぎたすべてのアイテムと一緒にフォルダーです。 Enums、Images、Commandsなど.

60
Sheridan

ほとんどの人はあなたが言及した「標準」構造を使用します

  • 型/
    • CarModel.cs
    • DriverModel.cs
  • ViewModel /
    • CarViewModel.cs
    • DriverViewModel.cs
  • 見る/
    • CarView.xaml
    • DriverView.xaml

人気がある理由は、Models、ViewModels、Viewsを異なるアセンブリに配置できるべきだと主張する人もいるからだと思います。

また、この構造を使用すると、Converters/、Resources/など、他のWPFスタッフ用のフォルダーを簡単に追加できます。

私のチーム内では、この構造を使用していますが、名前を複数形にしています（したがって、Models/ViewModels/Views）。

ただし、ほとんどの場合、モデルクラスは他のアセンブリ/名前空間で定義されます。その場合、Models/フォルダーすらありません。

大規模なプロジェクトの場合は、Models/、ViewModels/、およびViews/にサブフォルダーを追加します

完全を期すために、「機能駆動型」構造を使用している少数の人々を見つけることができることに言及する価値があります。

  • 車/
    • CarModel.cs
    • CarViewModel.cs
    • CarView.xaml
  • ドライバ/
    • DriverModel.cs
    • DriverViewModel.cs
    • DriverView.xaml

しかし、それは非常にまれです。

22
Benoit Blanchon

私が普段持っているものは次のようになります：

  • メインアプリケーション（.exe）-グローバルスタイルなど
  • Common Lib WPF-WPFの基本クラスとヘルパー
  • Common Lib General-モデルの基本クラスとヘルパー
  • インフラストラクチャ-依存性注入、ロギングなど
  • VMのインターフェース
  • Mのインターフェース
  • ビューと対応するViewModelを含むいくつかのライブラリ-ここでの分割も可能です
  • モデルを含むいくつかのライブラリ

すべての依存関係は、DIを介してのみ解決されるインターフェイスに基づいています。

2
Jaster

友達、これに似た問題に対して私が見つけた解決策は、App.xaml（およびApp.xaml.cs）のみで、WPFというタイプのプロジェクトを別個に作成し、Startupと呼びました。

その中で、ViewとViewModelのプロジェクトを参照します。そのため、ビューには依存関係がなく、ViewModelはビューとビジネスのみを「認識」します。

App.xaml.csでMainWindowを宣言およびインスタンス化してから、アプリのいくつかの基本的なプロパティをロードし、ページLoginに移動します（Windowとその中で閲覧する複数のページで作業しています）。

enter image description here

2
Rodolfo Gaspar