设计决策：（EF&；WCF）健谈还是矮胖？

我有一个实体框架（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) { }

或者像这样：

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) { }

我想这是一个矮胖和健谈的问题

---

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

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

在编程上，我可能会选择chunky选项，而不需要将项目与4个单独的调用组合在一起

---

决定，决定。

要反驳克里斯的回答：

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

如果我们以一种简陋的方式做事情，配置下载会让doors离线超过一分钟

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

---

重新迭代：决策，决策。

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

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

---

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

您可以走一条中途路线，根据您的需求，有几种方法加载项目实体：-

LoadProjectLight(int projectId)
LoadProjectFull(int projectId)

前者只加载到对象图的“顶层”，即项目实体，后者加载整个对象，使用.Include（）引入所需的图形部分

---

当您只需要顶层（如项目主列表）时，可以使用Light方法；当您需要整个图形（如在详细视图中编辑对象）时，可以使用Full方法。

因此，经验法则是：如果您没有时间进行chunky，而您只有时间进行chatty，选择健谈的方式是有道理的明白了。是的，但你只是把决定权推给了开发者/消费者。这可能是有道理的，但我真的在寻找一个全面的理由。例如，粗块调用是否更容易失败？聊天电话是否太难处理？诸如此类。我想投票支持健谈。原因是，矮胖更容易。而且，我是按小时计酬的！