设计决策：（EF＆amp; WCF）Chatty还是Chunky？

Question

我有一个Entity Framework（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的问题。

这只是一种“依赖于”某种情况还是在这些设计决策中有一般的经验法则？我听过有关健谈的论据，而且我听说过大块的论据。说实话，他们似乎都有道理;既有利益又有负面影响。

Answer 1

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

以编程方式，我可能会选择粗略的选项，而不必将项目与4个单独的调用分开。

决定，决定。

Answer 2

对抗克里斯的回答：

我帮助组建的系统是一个与Windows服务器通信的嵌入式系统。肯定有可能以厚实的方式做事。但是，嵌入式系统是一个访问控制器，它根据徽章编号的访问级别读取徽章并打开（或不打开）门。

如果我们以厚实的方式完成任务，那么配置下载将会离线超过一分钟。

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

重新迭代：决定，决定。

Answer 3

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

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

您可以决定不实施fistPartIndex＆amp; amp;在项目的初始阶段，lastPartIndex，但至少API将是未来的证据，我认为这是我开始定义公共服务时决定的一个非常重要的部分。

Answer 4

根据您的要求，您可以选择使用几种方法加载项目实体的中途路线： -

LoadProjectLight(int projectId)
LoadProjectFull(int projectId)

前者只是加载对象图的“顶层”，即Project实体，后者将加载完整对象，使用.Include（）来引入图形所需的部分。

当你只需要顶级依赖时，你可以使用Light方法。项目的主列表，然后当您需要整个图表时的完整方法，例如在详细信息视图中编辑对象。