WPF + REST + EF：组织DTO的最佳方式是什么？

Question

我有一个包含3层的WPF MVVM应用程序：

1. UI
2. 服务
3. DAL

和一些项目，例如Order。我需要3个DTO：

1. MVVM层的类，带有PropertyChanged通知;
2. Json反序列化器的类（通过REST API获取对象）
3. 实体框架类（DB中的缓存数据）。

好吧，我可以在所有三种情况下使用ONE类，但这将混合使用不同的属性（来自EF，JSon，MVVM）和层的多余依赖性。

另一种方法：制作3个类，每个层都有自己的类，并使用AutoMapper进行快速转换。不错，但是每个DTO类的3个几乎完全相同（90％）的副本......不是优雅的解决方案。

最好的方法是什么？你用什么？ 感谢。

Answer 1

  

最好的方法是什么？你用什么？

第二种方法，即您可以在单独的程序集中定义业务对象，您可以从所有应用程序中引用它们。这些类不应实现任何特定于客户机的接口，例如INotifyPropertyChanged，而应该是仅包含业务逻辑的纯POCO类。

在WPF应用程序中，然后创建一个视图模型类，该类实现INotifyPropertyChanged接口并包装业务对象的任何属性，以便从视图中公开和绑定。

视图模型随后具有对模型的引用，视图将绑定到视图模型。这通常是在WPF应用程序中（或应该）实现MVVM设计模式的方式。视图模型类包含应用程序逻辑，例如，如何在更改数据绑定属性值时通知视图，并且模型包含所有平台和应用程序中相同的业务逻辑。

当然这意味着你最终会得到更多的课程，但这不一定是坏事，因为每个班级都有自己的责任。

视图模型的职责是充当特定于应用程序的XAML视图的模型，而模型类的职责是实现业务逻辑，而DTO类的职责是简单地在不同的数据之间传输数据。层。这是一个更好的解决方案 - 至少在我看来，也可能在大多数企业架构师的意见中 - 比定义一个实现所有类型的UI特定逻辑的类只是为了减少类的数量。