MVVM，UWP & Template 10 -模型与视图技术无关

Question

我对MVVM的理解是，view负责用户表示逻辑，视图模型用于交互逻辑，以及来自UI独立模型类的特定数据转换，以及从数据角度表示业务域的模型本身。

关键是模型类应该是UI独立的。

下面是UWP开发模型和模板10 BindableBase，模型类应该是从它们派生出来的。它非常方便，但它将模型绑定到特定的UI实现，即UWP + Template 10。

我有一个数据访问层，我想直接将域对象作为模型提供给UI。这个领域相当复杂。我不想做的是在UI中重新实现数据域对象，也不想用UI特定的函数污染它。

对此有什么想法吗？

谢谢

Answer 1

恕我直言，我想你可能想错了。

MVVM的目标是像您描述的那样分离您的逻辑。这种分离的目的是简化代码。这是否使视图模型具有可测试性和单独的关注点？是。但是，我认为这些是简单性的次要目标--这使您的代码易于管理和可维护。

另一种说法是。

对于XAML应用程序来说，MVVM是一种非常棒的方法。但是，如果MVVM没有使您的视图模型具有可测试性或单独的关注点，那么MVVM仍然是XAML应用程序的一种很好的方法，因为它简化了代码--更小、更简单和更孤立。

每一分钱都值。

您可能会争辩说，MVVM创建了另一层代码，开发人员必须了解这些代码，然后才能对基本代码进行推理和贡献。我会同意。但是，我不认为MVVM是不可行的。与逻辑的其他耦合相比，添加的层是微不足道的。

现在请回答你的问题。

您的数据层对象(可能是数据传输对象)非常类似于您的UI对象，可能是一个模型。开发人员的本能迫使您通过多态性、代码生成或接口将类似的事情结合起来，以避免增加bug、复杂性和测试的机会。

考虑一下这个。

在数据层中创建的对象是为数据层创建的。同样，在UI层中创建的对象也是为UI层创建的。结构相似性是领域相似性的副产品。当然，它们是相似的:然而，它们的意图却并非如此。你为什么要合并他们？

你已经看到问题了。

您唯一的不同之处可能是数据层构造器接受某种类型的数据读取器并填充属性。这对于数据层来说是完美的，但对于UI层则不合适。UI层可能有消息传递事件或处理交互的自定义方法。这对于UI层来说是完美的，但对于数据层则是不合适的。

那么，相似性在哪里呢？

我认为开发人员，包括我自己，倾向于认为类似的事情可能是相同的。您的数据相关特性不属于您的UI，也不属于其他方式。相反，您需要做的是看到相似之处，但要认识到它们是完全不同的对象，不应该得到相同的对象。

我们很懒。

重复的代码与测试和bug无关。不怎么有意思。这是关于我们作为开发人员是如何痴迷于“更聪明而不是更努力”的，以至于我们倾向于轻视“努力工作”。如果一个对象是为一个层构建的，那么它应该在该层中，而不是由另一个层共享。我强烈的感受到了这种感觉。

正确的解决办法

最简单的解决方案是让DTO从DataLayer.Object在数据层上序列化，然后在UI层上反序列化为UILayer.Model。这是最简单和最简单的方法，并充分允许您强制数据和对象API供其独特的层使用。

这意味着有两个几乎相同的对象:一个在数据层上，一个在UI层上。但这并不意味着有两个相同的物体。它们不是完全相同的，因为它们具有每个层、每个层特有的功能。

如果没有功能怎么办？

想知道这是否适用于没有添加功能的对象和模型是有意义的。我坚信，在没有添加功能的任何层中，对象和模型都只是在等待添加该功能。如果您假设没有并且构建到这个假设中，您将迫使未来的维护开发人员永远不添加特定于层的功能。

这有关系吗？

我想是的。为什么？因为对象或模型中特定于层的功能允许我在数据对象或模型的上下文中，而不是在manager、helper或utility等外部构造中，为我的体系结构和实现增加复杂性(而不是复杂性)。毫无疑问，Type.DoSomething比Helper.DoSomethingForType(Type)容易。

我其实有三个

让您知道，我是这样做的:在我的项目中，您和我可能拥有类似的数据层/服务。但是，我的UI层实际上有两个模型--不是一个。(让我们假设用户是数据类型。)我的UI层有json.User和Models.User。json.User是一个基本的基本结构，从我的服务中反序列化，并且与服务对象完全匹配。但是我的UI很少需要Service表面/结构。

服务(DataLayer.User)>Service> UI(json.User > Models.User)

因此，然后使用json.User创建Model.User，其结构完全满足UI层的需求--包括方法、事件和消息传递结构。当我向UI添加特性时，我可以自由地更改我的Models.User --包括合并来自其他/新数据服务的数据。此外，Model.User可以实现数据层对象和json对象从未(或不需要)实现的INotifyPropertyChanged。

考虑一下这个

如果您将模型保持独立，并且使一个代码库不会对另一个代码库产生不适当的影响，那么数据库中的任何更改或数据服务/层中的更改都不需要更改UI层，即使您更改了API表面。只有UI层中的反序列化提示的json.User更改或调整才会受到影响。对我来说，这只有道理。

但是测试和bug呢？

测试很少测试结构。数据结构是您可以添加到解决方案中的最简单的东西，很少会增加复杂性。你可以在大约一秒钟内对一个结构进行推理。你可以在大约一分钟内推理一种方法。结构的成本很低。他们的建筑成本也很低。如果您将初始结构从数据层复制/粘贴到UI层--我们都是这样做的。但这不是重复的代码。它只是构建类似的对象，适当地解耦。

我就是这么想的。