我想知道在WCF服务中是否推荐使用Self Tacking Entities(在实体框架中)?如果是的话,那么你能指导我一个教程,可以指导如何做到这一点?建议使用自追踪实体和WCF服务吗?
其实,我打算开发一个使用Prism和MEF和MVVM的WPF应用程序。我决定使用实体框架。我需要关于这种方法的建议和建议。
任何帮助将不胜感激。
我想知道在WCF服务中是否推荐使用Self Tacking Entities(在实体框架中)?如果是的话,那么你能指导我一个教程,可以指导如何做到这一点?建议使用自追踪实体和WCF服务吗?
其实,我打算开发一个使用Prism和MEF和MVVM的WPF应用程序。我决定使用实体框架。我需要关于这种方法的建议和建议。
任何帮助将不胜感激。
我想知道,如果使用自套结实体(实体框架)建议使用WCF服务 ?
这取决于你问谁。如果你问MS他们会告诉你是因为他们根本没有更好的报价。国有企业对这个很老的MS Connect suggestion作出了回应。问题是,EF本身具有terrible bad support两个实体图之间的合并更改(你必须这样做完全自己)和开发人员对MS平台上工作(有时也包括我)有一些共同的行为:
前两点是MS策略的结果,其中RAD成为设计师(或新近也是T4模板)的同义词。
我share @理查德对STE的看法。我会增加一个STE的另一个缺点 - 他们在参与者之间移动大数据集。如果您决定从服务器获取实体图,则更改图中的单个实体并将数据推回,它们将再次传输整个图。只传输更改的实体会导致与STE的核心逻辑发生冲突。我也担心他们会在每个实体级别而不是按物业级别完全跟踪更改。如果修改具有较大二进制或字符串数据的实体,可能会导致在服务和数据库之间以及服务和客户端之间传输太多不需要的数据。
无论如何,对于低数据流量和小实体的简单应用程序,他们可以很好地完成工作,并允许您快速构建应用程序,但无需严格区分问题。您将从服务中获取实体并将其直接绑定到WPF UI,并且他们将能够跟踪您的更改。稍后,您会将实体推回服务,并且他们将能够坚持更改。您的客户和服务将紧密结合,但在某些情况下,它可能足够好。