MVVMアプリケーションの設計[閉じた

Question

私はここで私のアプリケーションの設計について非常に懐疑的です.....

これが私のアプリケーションの図です

これは正しいですか ？？ OT私は何かを変える必要があります...

図を詳しく説明します....：

一般的なライブラリ：クラスエラーコード、ユーティリティクラスなどが含まれています
ロガー：ロギングフレームワーク
例外処理：例外を処理するためのフレームワーク

ビュー：contains：usercontrols、windows、ポップアップなどのビュー用のすべての異なるxaml

ViewModel：異なるビューのViewModelが含まれています。

モデル：含まれる...ビジネスレイヤー、データアクセスレイヤーなどのさまざまなレイヤーが保持されます

エンティティレイヤー：従業員、会社などのエンティティオブジェクトが含まれています...

ファイルボックス：ファイル/データベースからの読み取り/書き込みを指定しています。

Answer 1

あなたがあなたの質問で何をしようとしているのかを伝えるのは難しいですが、私の意見では、MVVMレイヤーは次のようになるはずです。

• モデル: ：生データと生データの検証。多分 INotifyPropertyChanged 同様に、しかし他に何もありません

• ViewModel: ：ビジネスロジック、データアクセス、ビジネスルールなどに基づく高度な検証

• ビュー: ：ユーザーがViewModelsと対話できるようにするかなりのUIレイヤー。他に何もありません。

たとえば、モデルにはaがあります File プロパティですが、ファイルダイアログを表示したり、ファイルをデータベースに保存したり、ファイルに.pdf拡張子があることを確認する責任は責任を負いません。そのようなものは、ViewModelの仕事です。

編集

あなたがあなたの質問に対して行ったアップデートを見ます。それはOKスタートですが、ここに私が抱えている問題があります：

• モデルは生データオブジェクトである必要があります。プロパティの長さを検証するようなものよりも高度なものを含めるべきではありません。

• 正直なところ、ビュー、モデル、およびビューモデルを3つの別々のレイヤーに分離することはお勧めしません。私は一度それをしました、そしてそれはメンテナンスの悪夢であることが判明しました。今、私はすべての関連オブジェクトをまとめました。たとえば、私は置きます FileModel, FileViewModel, 、 と FileView 一緒に、そして SearchModel,SearchViewModel, 、 と SearchView 一緒

• データベースとの間ですべての読み取り/書き込みデータを実行する責任のあるデータアクセスレイヤーを作成します（これはあなたの「エンティティレイヤー」である可能性があります）。

• 小規模なプロジェクトでは、エンティティオブジェクトをモデルとして使用する傾向があるため、モデルはDALレイヤーの一部になりますが、これは推奨されていません。

• 忘れないでください、MVVMを使用すると、ビューモデルはあなたのアプリケーションであり、あなたの見解ではありません。ビューは、ビューモデルにあるものを反映する必要があり、その逆ではありません。