Breeze 客户端的实体是反模式的吗？

我以前使用过RIA服务，现在正在测试Breeze Sharp

RIA和Breeze给人的印象是，在服务器/中间层上看到的就是在客户端上看到的。为了支持这一点，客户机和服务器上都使用了术语实体。它真的是一个实体，还是一个表示模型或客户机上的模型

对于具有一个或两个级别的实体图的较小系统，认为客户机和服务器都是相同的可能没有错误。对于图形深入到五到六个级别的大型系统，需要将实体转换为DTO以使其变得简单。除非UI有一些实体的CRUD屏幕，否则大型应用程序最终会有更多的DTO和更少的实体。大多数情况下，这些DTO将表示UI所需的内容，并且相当于一个表示模型

---

为什么我们不能把客户在客户端的处理方式看作是模型而不是实体？

你可以随意调用客户端实体类：-（<）/p> 更严肃地说，让我们来看看这是一种反模式的说法背后的典型理由

客户端不是表示层 我想非常清楚这一点Breeze是为富web客户端应用程序设计的。Breeze客户端不是表示层；它有一个表示层。它也有自己的业务模型和数据访问层

术语“实体”和“DTO”对不同的人意味着不同的东西。我喜欢“实体”和in

Breeze客户端实体被称为Evans实体：“具有贯穿时间的不同标识和不同表示的对象。您还可以听到这些称为“引用对象”[]。Breeze实体不仅仅是财产袋；它们也有业务逻辑，您可以用自己的更多功能扩展它们

微风实体不是“演示模型”。它们独立于任何特定的UI表示，通常不实现表示关注点

它们的设计使它们可以直接绑定到视觉控件。这是一个轻松高效的设计决策。。。关于如何实现实体的决策。有些人——那些认为实体属性是反模式的人——会讨厌这一点。埃文斯对那个问题保持沉默。如果它冒犯了你，你可能不喜欢微风。往前走

发送实体还是DTO？ 我要说的是，这是一种错误的二分法

人们常说“通过网络发送实体是一种反模式，总是发送DTO”。这项措辞拙劣的法令背后有着合理的理由。当客户机和服务器实体类相同时，您已经将服务器的实现耦合到客户机的实现。如果模型在服务器上更改，则必须在客户端上更改，反之亦然，即使更改仅与其中一个层相关。这可能会影响您独立开发服务器和客户端代码的能力。我们可以接受这种耦合是一种权宜之计（权宜之计也很重要！），但没有人想要它

Breeze客户端实体类在形状和业务逻辑上都不必与服务器实体类相同。当您在Breeze中查询时，您将实体数据放到连线上，并将其转换为客户实体；保存时，将客户机实体数据放到线路上，并在服务器上将其转换为服务器实体。DTO可能涉及任何一个方向。重要的事实是，这些类可以不同

当然，它们在概念上是相关的。如果

Customer

实体的含义在两种表示形式之间存在很大差异，那么在这两种表示形式之间转换数据将非常困难。无论是否使用显式DTO，这都是正确的

我们还要承认，当类实际上相同时，在两个方向上转换数据更容易。当它们不同时，您需要支付映射税，并且您可能会失去在客户端上编写Breeze LINQ查询的能力。如果你愿意，你可以纳税。微风不在乎

我倾向于从双方相同的课程开始，并在必要时改变它们。这在RIA服务和DevForce的高比例课程中表现良好。最重要的是，对我来说，在需要的时候重新划分班级从来都不困难

担忧者夸大了共享类定义的风险，低估了映射层的成本，而映射层的好处在应用程序的生命周期中很少在实践中实现。

何时使用演示模型 你写道：

对于图形深入到五到六个级别的大型系统，需要将实体转换为DTO以使其变得简单。。。大多数情况下，这些DTO将表示UI所需的内容，并且相当于一个表示模型

根据我的经验，只有假设客户机只是将实体粘贴到屏幕上，这才是正确的。但是我已经规定客户机是一个应用程序，而不是表示层

我进一步指出，客户机上需要域模型的原因与服务器上需要域模型的原因相同：对域进行推理。您可以独立于演示文稿执行此操作。我假设您的实体将以某种方式出现在多个屏幕上，并遵循不同的表示规则。这是同一个模型，有很多种方式。我们称之为“围绕数据旋转”

无论在模型上放置多少面，底层模型数据和管理它们的业务规则都应该保持不变。这就是它成为“域模型”而不是“表示模型”的原因

FWIW，我的应用程序中总是有一个“表示模型”（也称为“视图模型”）来协调视图的活动。所以我不会问自己“PM还是模特？”。相反，我选择将可视控件直接绑定到mod