31

我们正在启动一个新的基于 Web 的产品，我们计划在其中通过 WCF 服务公开我们的业务逻辑。我们将使用 ASP.NET 4.0、C#、EF 4.0。将来我们希望基于这些服务构建 iphone 应用程序和 WPF 应用程序。我已经阅读了很多关于使用 POCO 与自我跟踪实体 (STE) 的内容，据我了解，STE 不适用于 Web 场景。任何人都可以更清楚地了解这个问题吗？

4

4 回答 4

37

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

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

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

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

您能提供此声明的引用吗？“STE 不适用于 Web 场景”

于 2010-09-28T18:10:52.697 回答
3

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

于 2012-10-30T09:44:52.440 回答
2

如果此服务将由您无法直接控制的任何应用程序使用，您可能应该强烈考虑将与 EF（或 nHibernate 或 Linq2Sql 或任何其他数据持久性管理解决方案）相关的任何事情从您的服务和数据中分离出来转移对象。这将使内部更改免受破坏客户端的影响。破坏客户通常是一件坏事。

于 2010-09-28T21:07:15.907 回答