自跟踪实体 vs POCO实体

31

我们正在启动一个基于Web的新产品,计划通过WCF服务公开我们的业务逻辑。我们将使用ASP.NET 4.0、C#和EF 4.0。未来我们希望基于这些服务构建iPhone应用程序和WPF应用程序。我一直在阅读有关使用POCO与Self Tracking Entities (STE)的文章,我的理解是STE在Web场景下效果不佳。有人能否对这个问题提供更多的解释?


我很感激这个问题早些时候被提出,但我很好奇你最终在POCO vs STE的情况下做出了什么决定? - Brett Rigby
4个回答

37

对我来说,STE是一个完全错误的概念。它只是DataSet的另一种实现。

  • 在ASP.NET应用程序中,您需要将STE存储在请求之间的某个位置。在第一个请求中,您将查询数据源以获取STE并在页面中提供数据。在下一个请求(回发)中,您将希望使用从浏览器返回的数据修改STE。为支持跟踪,您将需要使用与第一个请求中相同的STE => 您将需要在viewstate中(如果要使用ASP.NET WebForms)或会话中存储STE。
  • STE对于SOA或互操作性毫无用处。跟踪逻辑是STE的一部分=它在客户端运行。如果您在服务中公开STE,则立即期望客户端使用包含在STE逻辑中的相同跟踪功能。但这些功能不会自动提供给其他方。在.NET中,您拥有它们,因为您与STE共享程序集。但在其他平台上,您必须说明开发人员如何实现STE逻辑,以使其在您的一侧起作用。这可能会是最限制您的情况,因为涉及iPhone应用程序。

2
如果您对额外的数据库查询感到满意,那么您根本不需要使用STE——除非您需要修改复杂对象图。您可以让带有POCO代理的ObjectContext为您跟踪更改。 - Ladislav Mrnka
"STE对于SOA或互操作性毫无用处。" 我完全同意。不幸的是,人们似乎坚持将SOA和WCF视为远程调用。当然,这是可以做到的,但这样你就需要对客户端有很高的信任度。 - Daniel Auger
6
@jfar: 哈哈。这就是downvote的原因吗?难道你不认为Kumar需要解释一下吗?标签显示它是MVC问题,而问题是关于ASP.NET 4.0和未来扩展到iPhone的。提到viewstate和互操作性是完全合理的。 - Ladislav Mrnka
也许STE并不是ASP.Net场景下最好的选择,你可以使用DTO来获得更加解耦的解决方案,特别是它在互操作性(SOA)方面的能力。 - Jonathan Escobedo
也许只是我个人的看法,但数据访问层内部的操作应该仅限于它本身和可能在其上方的业务层;我认为在向更高层次的堆栈公开数据时,应使用ViewModels(或类似的东西),将数据层的复杂性抽象出来,使任何客户端应用程序或其他消费者都不会意识到。我的Web应用程序(无论是ASP .Net还是MVC)完全不知道我在下面使用的STE,因为我认为在从顶部的Web层直接向下链接数据/模型层(其中定义了STE)的n层应用程序中没有意义。 - Brett Rigby
显示剩余3条评论

8

自跟踪实体在带有WCF的MVC Web中表现非常出色。我参与了两个项目,其中一个已经投入生产使用,另一个快要完成。

如果使用POCO,则会丢失通过网络的任何更改跟踪,这会带来很多额外的麻烦,因为EF现在必须重新查询状态信息。如果您正在使用EF和WCF,则STE可以解决很多问题,并使整个持久性管道非常流畅。


能否提供此说法的引用?“STEs在Web场景下效果不好”


1
你是如何在请求之间保持STE的持久性的(例如GET-->POST)? - Paul Hiles
@jfar,在WCF场景中,如果使用STE(自跟踪实体),则“平台无关服务”的概念将丢失。例如,如果有一个Java客户端应用程序希望与WCF服务进行交互,那么该Java客户端应用程序如何在客户端获取SET(自跟踪实体)?不幸的是,它根本无法获取!这意味着,如果我们使用STE,则我们的WCF服务只能由在.Net中构建的客户端使用。这太可怕了,不是吗? - Baig

3

2
如果该服务将被任何您无法直接控制的应用程序使用,您应该考虑将与EF(或nHibernate或Linq2Sql或任何其他数据持久化管理解决方案)有关的任何内容分离出来,包括服务和数据传输对象。这将使内部更改不会影响客户端。破坏客户端通常是一件不好的事情。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接