WPF + REST + EF：DTOを整理する最良の方法は何ですか？</p> <ol> <li>UI</li> <li>サービス</li> <li>DAL</li> </ol> <p>といくつかの項目、例えば、発注用：

Question

私は3つの層を持つWPF MVVMアプリを持っています。私は3を必要とするDTO：

1. PropertyChanged通知を持つMVVM層のクラス。
2. Jsonデシリアライザのクラス（REST APIでオブジェクトを取得）
3. Class for Entity Framework（DBのキャッシュデータ）。

まあ、私は3つすべてのケースでONEクラスを使用できますが、これはさまざまな属性（EF、JSon、MVVM）と余分なレイヤーの依存関係が混在しています。

もう1つの方法：3つのクラスを作成し、各レイヤーに独自のクラスがあり、その間に高速変換にAutoMapperを使用します。悪くはないが、それぞれのDTOクラスの3つのほぼ同じ（90％）コピー...エレガントでない解決策。

最良のアプローチは何ですか？あなたは何を使うのですか？おかげさまで

Answer 1

最良のアプローチは何ですか？あなたは何を使うのですか？

2つ目の方法は、ビジネスオブジェクトをすべてのアプリケーションから参照できる別のアセンブリで定義することです。これらのクラスは、INotifyPropertyChangedなどのクライアント固有のインターフェイスを実装するのではなく、ビジネスロジックのみを含む純粋なPOCOクラスである必要があります。

WPFアプリケーションでは、次に、INotifyPropertyChangedインタフェースを実装するビューモデルクラスを作成し、ビューに公開してバインドするビジネスオブジェクトのプロパティをすべてラップします。

ビューモデルにはモデルへの参照があり、ビューはビューモデルにバインドされます。これは、通常、MVVMデザインパターンがWPFアプリケーションでどのように実装されるか（または実装されるべきか）です。ビューモデルクラスには、アプリケーションロジックが含まれます。たとえば、データバインドプロパティ値が変更されたときにビューに通知する方法、およびモデルにはすべてのプラットフォームおよびアプリケーションで同じビジネスロジックが含まれます。

もちろん、これは合計でより多くのクラスになることを意味しますが、これはそれぞれのクラスが独自の責任を負うため必ずしも悪いことではありません。

ビューモデルの責任は、アプリケーション固有のXAMLビューのモデルとして機能する一方、モデルクラスの責任はビジネスロジックを実装することであり、DTOクラスの責任は、異なる層。これは、クラスの数を減らすためだけに、あらゆる種類のUI固有のロジックを実装する単一のクラスを定義するよりも、少なくとも私の意見で、おそらく大部分のエンタープライズアーキテクトの意見では、はるかに優れた解決策です。