自我跟踪实体与POCO实体
我们正在开始一个新的基于networking的产品，我们计划通过WCF服务来展示我们的业务逻辑。 我们将使用ASP.NET 4.0，C＃，EF 4.0。 今后，我们希望基于这些服务来构buildiphone应用程序和WPF应用程序。 我一直在阅读很多关于使用POCO vs自我跟踪实体（STE）的信息，从我的理解来看，STE在Webscheme中效果不佳。 任何人都可以在这个问题上更多地了解？
对我来说，STE是绝对错误的概念。 这只是DataSet的另一个实现。
- 在ASP.NET应用程序中，您将不得不在请求中的某处存储STE。 在第一个请求中，您将查询您的数据源以获取STE并在页面中提供数据。 在下一个请求（回发）中，您将要修改从浏览器返回的数据STE。 为了支持跟踪，您必须使用与第一个请求中相同的STE =>您必须将STE存储在视图状态（如果您想使用ASP.NET WebForms）或会话中。
- STE对SOA或互操作性没有用处。 跟踪逻辑是STE =它在客户端上运行的一部分。 如果您在服务中暴露STE，您将立即希望客户端使用STE逻辑中包含的相同跟踪function。 但是这些function不会自动提供给其他方面。 在.NET中，你有他们，因为你与STE共享程序集。 但是在其他平台上，您必须向开发人员解释如何实施STE逻辑，以使其在您身边工作。 由于iPhone应用程序的原因，这对您来说可能是最有限的情况。
自跟踪实体在WCF场景下可以在MVC Web中完美工作。 我参与了两个使用它们的项目（一个在生产中，一个在差不多）。
使用POCO，您将失去对电线的任何更改跟踪，这会造成很多额外的痛苦，因为EF现在必须重新查询状态信息。 如果您使用EF和WCF STE解决了很多问题，并使您的整个持久性pipe道真正平滑。
你能否提供这种说法的引用？ “STEs在networking场景中效果不佳”
请参阅http://msdn.microsoft.com/en-us/data/jj613924.aspx ，因为STE不再推荐！ Microsoftbuild议使用任何ASP.NET Web API，WCF数据服务或entity frameworkAPI（复杂操作）
如果这个服务将被任何你没有直接控制的应用程序所使用，那么你应该强烈的考虑从你的服务和你的数据中分离任何与EF（或者nHibernate或者Linq2Sql或者任何其他数据持久化pipe理解决scheme）转移对象。 这将隔离客户的内部变化。 打破客户通常是一件坏事。
