自我跟踪实体与POCO实体

Question

我们正在开始一个新的基于Web的产品，我们计划通过WCF服务公开我们的业务逻辑。我们将使用ASP.NET 4.0，C＃，EF 4.0。将来我们希望基于这些服务构建iphone应用程序和WPF应用程序。我一直在阅读很多关于使用POCO和自我追踪实体（STE）的内容，据我所知，STEs在网络方案中效果不佳。任何人都能更清楚地了解这个问题吗？

Answer 1

对我来说，STE是绝对错误的概念。它只是DataSet的另一个实现。

• 在ASP.NET应用程序中，您必须将STE存储在请求中的某个位置。在第一个请求中，您将查询数据源以获取STE并在页面中提供数据。在下一个请求（回发）中，您将需要使用浏览器返回的数据修改STE。要支持跟踪，您必须使用与第一个请求中相同的STE =＆gt;您必须在视图状态（如果要使用ASP.NET WebForms）或会话中存储STE。
• STE对SOA或互操作性无用。跟踪逻辑是STE =它在客户端上运行的一部分。如果您在服务中公开STE，您会立即期望客户端将使用STE逻辑中包含的相同跟踪功能。但这些功能不会自动提供给其他方面。在.NET中你有它们，因为你与STE共享程序集。但是在其他平台上，您必须向开发人员解释如何实现STE逻辑以使其在您身边工作。由于iPhone应用程序，这可能是最受限制的情况。

Answer 2

自我跟踪实体在具有WCF场景的MVC Web中完美运行。我参与了两个使用它们的项目（一个在生产中，一个在差不多）。

使用POCO，您将失去对线路的任何更改跟踪，这会造成很多额外的痛苦，因为EF现在必须重新查询状态信息。如果您使用EF和WCF STE解决了很多问题并使整个持久性管道变得非常流畅。

---

您可以为此声明提供引用吗？ “STE不适合网络场景”

Answer 3

请参阅http://msdn.microsoft.com/en-us/data/jj613924.aspx，因为不再推荐使用STE！ Microsoft建议使用任何ASP.NET Web API，WCF数据服务或实体框架API（复杂操作）

Answer 4

如果此服务将由您无法直接控制的任何应用程序使用，您可能会强烈考虑与您的服务中的EF（或nHibernate或Linq2Sql或任何其他数据持久性管理解决方案）进行任何分离和您的数据传输对象。这将使内部更改与破坏客户端隔离开来。打破客户通常是件坏事。