質問

現在、新しいWpfアプリケーションにPrismを導入し、MVVMパターンを使用しています。 Wpfアプリケーションを構築する私の最初のアプローチは、モデルクラスを保持するプロジェクト、ビューモデルクラスを保持するプロジェクトなどを追加することでした。ただし、Prismを使用する場合(および一般的には一般的には..)、これは悪い構造だと思います。

Prismでは、物事を異なる論理モジュールに構造化します。同じ物事に関連するものはすべて同じモジュールに配置されます。したがって、これは、アプリケーションの論理部分に関連するすべてをこの部分のモジュールに配置する必要があることを示しています。これは、このコンポーネント、関連するビューモデル、および必要なモデルクラスのいくつかの異なるビューを保持する場合があります。ただし、このアプローチを使用すると、モデルがソリューションの周りに散らばってしまいます。モデルはデータベースに結び付けられるため、結局これはおそらく悪いアプローチであると思います。私はNHibernateを使用しているため、データベースは実際には「視覚的」ではありません。しかし。

だから、3つの異なる構造があります。これらのいずれかが一般的に望まれていますか?または、アプリケーションを構成する別の方法がありますか?

  1. プロジェクト" Model"、" ViewModel&quot ;、およびUserControlsを保持するプロジェクト。など。
  2. 1つのプロジェクトまたは論理パーツ-このパーツの関連ビュー、ビューモデル、モデルの両方を含みます。
  3. 1つのプロジェクトまたは論理部分-ビューとビューモデルを含むが、モデルは別のプロジェクトで定義されています。論理的な関係がある場合は、すべてのモデルクラスに対して1つのプロジェクトでさえあります。

ご意見は大歓迎です!

役に立ちましたか?

解決

別のプロジェクトにモデルを置くことは問題ありません。プリズムスタイルのアーキテクチャから本当に利益を得るのに十分な大きさであれば、それをお勧めすると思います。モデルはVとVMの垂直サイロに限定されず、すべての下にある下層です。

ビューとビューモデルは、互いに近くに住むのが理にかなっています。ビューまたはビューモデルの再利用を見つけるかもしれませんが、そうでない場合でもストレスをかけないでください。とはいえ、ビューは常に特定のビューモデルに常に関連付けられているわけではなく、その逆も同様です。たとえば、すべての売上を表示するビューモデルと、現在の四半期をフィルタリングするビューモデルがありますが、両方を同じビューにリグできます。反対に、同じビューモデルに円グラフと棒グラフがあります。したがって、これらを分割するのは、カットして乾燥させるほどではありません。ただし、モデルのペアを表示/表示するだけでなく、より大きなチャンクが見つかる場合があります。セールス対顧客管理など。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top