设计决策：（EF 和 WCF）健谈还是矮胖？答案

【问题标题】：Design Decision: (EF & WCF) Chatty or Chunky?设计决策：（EF 和 WCF）健谈还是矮胖？
【发布时间】：2011-06-24 21:21:28
【问题描述】：

我有一个包含多个多层导航属性的实体框架 (v4) 实体。它可能是一个非常深的物体。生成的实体可以很小，也可以很大。它永远不会超大。永远不会有兆字节的数据或其他任何东西。

另外，我并不想解决有效负载大小的问题或我收到的任何错误。我只是想确定哪种是这种情况的最佳解决方案。

让我们将我的实体框架实体称为项目记录。

像这样构建 WCF 方法是不是最聪明：

public Project GetProject(int projectId) { }

或者像这样：

public Project GetProject(int ProjectId) { }
public Project GetProjectPart1(int ProjectId) { }
public Project GetProjectPart2(int ProjectId) { }
public Project GetProjectPart3(int ProjectId) { }
public Project GetProjectPart4(int ProjectId) { }

我猜这是 Chunky 与 Chatty 的问题。

这只是一种“视情况而定”，还是在这些设计决策中存在一般经验法则？我听说过关于健谈的争论，也听说过关于大块的争论。老实说，它们似乎都有道理。两者都有好处，也都有负面影响。

【问题讨论】：

我想为 Chatty 投票。原因在于，Chunky 更容易。而且，我按小时获得报酬！

标签： wcf entity-framework design-patterns entity-framework-4

【解决方案1】：

我想这可能取决于环境。如果这是一种公共 WCF 方法，那么通过 http 发送大量信息可能会出现问题。但是，在本地环境中，您还有其他选择。

以编程方式，我可能会选择厚实的选项，而无需通过 4 个单独的调用将项目拼凑在一起的开销。

决定，决定。

【讨论】：

【解决方案2】：

反驳克里斯的回答：

我帮助组装的一个系统是一个与 Windows 服务器通信的嵌入式系统。以粗略的方式做事当然是可能的。然而，嵌入式系统是一个访问控制器，它可以读取徽章并根据徽章编号的访问级别打开（或不打开）门。

如果我们以粗略的方式做事，配置下载会使门离线超过一分钟。

以健谈的方式做事意味着每个人的“聊天”都可以在不离线的情况下处理。当然，整体下载时间更长，但从来没有停机时间。

重申：决定，决定。

【讨论】：

所以，这个经验法则是：如果你没有时间做粗话，而你只有时间聊天，那么选择健谈的方法是有意义的。 ;) 明白了。

【解决方案3】：

当我无法在两种做事方式之间做出选择时，通常意味着这两种方式实际上都是有用的。因此，作为一种折衷方案，就纯 API 而言，我会这样定义：

public Project GetProjectPart(int ProjectId, int firstPartIndex, int lastPartIndex) { }

您可以决定在项目的初始阶段不实现对 firstPartIndex 和 lastPartIndex 的处理，但至少 API 将是未来的证明，我认为这是我开始定义公共服务时决定的一个非常重要的部分.

【讨论】：

是的，但您只是将决策选择推给了开发人员/消费者。这可能是有效的，但我真的一直在寻找一些首要原因。例如，chunky 调用是否更有可能失败？聊天电话是否太难处理？以此类推。

【解决方案4】：

根据您的要求，您可以选择几种方法来加载项目实体：-

LoadProjectLight(int projectId)
LoadProjectFull(int projectId)

前者只会加载到对象图的“顶层”，即项目实体，而后者将加载完整的对象，使用 .Include() 来引入所需的图部分。

当你只需要顶层时，你会使用 Light 方法，例如项目的主列表，然后在需要整个图表时使用 Full 方法，例如在详细信息视图中编辑对象。

【讨论】：