自我跟踪实体与POCO实体

我们正在开始一个新的基于网络的产品，我们计划通过WCF服务公开我们的业务逻辑。我们将使用ASP.NET 4.0，C＃，EF 4.0。未来我们希望基于这些服务构建iphone应用程序和WPF应用程序。我一直在阅读很多有关使用POCO vs自我跟踪实体（STE）的信息，并且从我的理解中可以看出，STE在Web方案中效果不佳。任何人都可以在这个问题上找到更多的信息自我跟踪实体与POCO实体

来源

2010-09-28 Kumar

我明白这个问题是前一阵子问过的，但我很好奇你最终决定了什么POCO vs STE的情况？ – 2012-07-13 13:35:44

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

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

来源

2010-09-28 18:39:28

在ASP.NET中，为什么不直接在第一次请求时显示STE并在回发时从数据库中获取STE，更新字段并保存？ – 2010-09-28 18:44:14

如果您对额外的数据库查询感到满意，除修改复杂的对象图外，根本不需要STE。你可以让ObjectContext（带有POCO代理）来跟踪你的变化。 – 2010-09-28 18:49:39

“STE对于SOA或互操作性无用。”我完全同意。不幸的是，人们似乎坚持将SOA和WCF视为远程处理。当然，它可以完成，但是你对客户非常信任。 – 2010-09-28 19:09:27

自跟踪实体在WCF场景下可以在MVC Web中完美工作。我参与了两个使用它们的项目（一个在生产中，一个在生产中）。

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

您能否提供此声明的引用？ “STE在网络场景下效果不佳”

来源

2010-09-28 18:10:52 jfar

你如何在请求之间保持你的STE（例如GET - > POST）？ – 2011-01-19 12:42:46

@jfar，在WCF场景中，如果您使用STEs（又名自我跟踪实体），则“平台独立服务”的概念将丢失。例如，如果有一个Java客户端应用程序想要与WCF服务进行交互会发生什么。 Java客户端应用程序如何在客户端获取SET？不幸的是，它根本不能！意思是，如果我们使用STE，那么我们的WCF服务只能由建立在.Net中的客户端使用。可怕的是不是？ – Baig 2011-08-02 12:01:13

如果这个服务将被任何你没有直接控制的应用程序占用，你应该强烈考虑与EF（或nHibernate或Linq2Sql或任何其他数据持久化管理解决方案）来自您的服务和您的数据传输对象。这将隔离破坏客户的内部变化。打破客户通常是一件坏事。

来源

2010-09-28 21:07:15

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

来源

2012-10-30 09:44:52

自我跟踪实体与POCO实体

回答

相关问题