私はここで私のアプリケーションの設計に非常に懐疑的です.....
これが私のアプリケーションの図です
これは正しいですか ？？何かを変更する必要があります...
ダイアグラムを詳しく説明します....：
共通ライブラリ：クラスErrorCodes、Utility Classesなどが含まれています
ロガー：ロギングフレームワーク
例外処理：例外を処理するためのフレームワーク
ビュー：含まれています：UserControls、Windows、Popupsなどのビューのすべての異なるXAML
ViewModel：さまざまなビューのViewModelが含まれています。
モデル：含まれています...ビジネス層、データアクセス層などのさまざまな層を保持します
エンティティレイヤー：従業員、会社などのエンティティオブジェクトが含まれています。
ファイルボックス：ファイル/データベースからの読み取り/書き込みを指定します...。
質問で何をしようとしているのかを判断するのは難しいですが、私の意見では、MVVMレイヤーは次のようになります。
モデル：生データと生データの検証。たぶんINotifyPropertyChanged同様ですが、他には何もありません
ViewModel：ビジネスロジック、データアクセス、ビジネスルールに基づく高度な検証など
ビュー：ユーザーがViewModelを操作できるようにするきれいなUIレイヤー。他には何もありません。
たとえば、モデルにFileプロパティがある場合でも、ファイルダイアログの表示、ファイルのデータベースへの保存、またはファイルの拡張子が.pdfであることの確認を担当する必要はありません。そのようなものがViewModelの仕事です。
編集
質問に対して行った更新が表示されます。スタートは大丈夫ですが、これが私が抱えている問題です。
モデルは生データオブジェクトである必要があります。プロパティの長さを検証するようなものよりも高度なものを含めるべきではありません。
正直なところ、Views、Models、およびViewModelsを3つの別々のレイヤーに分割することはお勧めしません。私は一度それをしました、そしてそれはメンテナンスの悪夢であることがわかりました。次に、関連するすべてのオブジェクトをまとめます。たとえば、、、、およびを一緒FileModelに、、、、およびを一緒に配置しますFileViewModelFileViewSearchModelSearchViewModelSearchView
データベースとの間ですべてのデータの読み取り/書き込みを行うデータアクセス層を作成します（これが「エンティティ層」である可能性があります）。
小さなプロジェクトでは、エンティティオブジェクトをモデルとして使用する傾向があるため、モデルはDALレイヤーの一部になりますが、これは推奨されません。
MVVMでは、ViewModelsがアプリケーションであり、Viewsではないことを忘れないでください。ビューはViewModelの内容を反映する必要があり、その逆ではありません。