自跟踪实体 vs 纯 POCO vs. 面向未来（3 层）

Question

这显然是一个已经讨论过很多次的话题，但是我在这里的处理角度有点不同。据我了解，STE 被认为是 POCO（它不以任何方式与 EF dll 绑定），它只是内部有一些额外的“东西”来处理自己的更改跟踪。假设以下应用程序层：

Proj.Web
Proj.Business
Proj.Model
Proj.DataAccess

假设不需要延迟加载，并且我们在 2 层设置中运行，我的理解是使用 STE 和 POCO 之间实际上没有区别。由于我们在网络上并且是一个断开连接的环境，因此选择是在回发上进行额外的 SQL 查询，或者必须附加实体并设置属性以根据需要进行修改。再次（如果我错了，请纠正我）代码看起来是相同的。

让我们考虑一个简单的示例，我们正在 Web 表单应用程序中处理回发：

Person p = PersonManager.GetById(2); //we use the "requery" method
PersonManager.Update(p);

//If we dig into PersonManager.Update() we'll see the following:
PersonRepository.ApplyChanges(p); //we're assuming STEs are used so this API is available
PersonRepository.SaveChanges();

假设稍后我们被要求将架构升级为 3 层，在 Proj.Bussiness 和 Proj.Web 之间引入 WCF 传输层，我们称之为 Proj.Services。如果我们一开始就使用 STE，我们的处境不是更好吗？我们所要做的就是将调用转发到业务层，而不必以任何方式修改它或存储库：

PersonService.Update(Person p)
{
    PersonManager.Update(p);
}

例如，如果我们使用 POCO（假设快照），我们必须以某种方式编码我们必须检查该实体是否已存在于上下文中（如果我们正在运行 2 层），如果不存在（3 层），则附加它并将其属性设置为已修改。当您不确定将来是否需要 3 层解决方案时，似乎还有很多工作要做。另一方面，如果您一直在针对 STE 进行编码，则您需要放入的唯一额外不必要（实际上不会造成任何损害）的代码是对 ApplyChanges() 的调用。否则我认为你不会丢失任何东西（再次假设不需要延迟加载）。您对此主题有何看法？

Answer 1

Ladislav Mknka 就为什么不使用 STE 提出了一些精彩的观点，但似乎这个问题确实没有一个万能的答案。例如，在我当前的 2 层项目中，它们可能是不必要的。不过，我们强烈希望将来使用 Silverlight 作为该项目的管理部分。这意味着我有一个用于模型和存储库的项目，希望能够在两个更高层的项目中使用。因此，一个运行 2 层，另一个运行 3 层（因为 Silverlight 需要服务）。据我所知，STE 的行为就像“连接”环境中的快照 POCO，因此在 2 层应用程序中使用它们不会损失/获得太多。然而，当我们添加 3 层 Silverlight 部件时，它们可能会被证明非常有用。希望我原来的帖子中描述的方法对于这两种类型的应用程序都适用。

显然还有其他方法可以解决这个问题，人们总是可以以一种确定特定实体是否被跟踪并根据该决定执行必要任务的方式编写存储库，我倾向于认为沿着这条路走下去将证明就开发工作而言，成本要高得多。我想只有时间才能证明一切。

Answer 2

STE 不太适合 Web 应用程序。他们的问题是它们的工作方式：

• 您加载 STE 并关闭上下文
• 使用 STE 中提供的数据
• 将数据推送回 STE
• 您将 STE 的更改应用到新上下文，它只是传递对象图中的所有更改

这似乎是很棒的功能，但也许它不是。对于 ASP.NET，它通常意味着：

• 加载初始检索请求的数据并将 STE 存储在某处
• 在后续更新请求中取回数据并将数据填充回存储的 STE

这很糟糕，因为它要求您将 STE 存储在会话或视图中状态。

您所描述的方法将以另一种方式发挥作用。您不会从初始请求中存储 STE，但您将在更新请求中调用您的服务两次

• 第一次获取新的 STE
• 第二次将更新后的 STE 传回

这也好不了多少，因为您有额外的远程调用，可以传输很多内容数据（对象图），然后将整个对象图传回。

显然，这两种方法都违反了一些架构思想

• 不要在 Web 应用程序中存储不必要的状态，因为 Web 应用程序应该尽可能少的状态
• 将远程调用减少到最低限度，因为它们非常昂贵 + 减少传输的数据量到您真正必须传递的数据

它们可以使远程场景变得更加容易，但它们有自己的成本（并且它们是.NET-.NET解决方案）。如果您没有远程场景 = 如果您不必使用 STE，就不要这样做。此外，有报告称其实施存在一些问题。在用户声音中，您甚至可以找到它们根本不起作用。