架构注意事项、WCF、EF(SET)答案

【问题标题】：Architecture consideration, WCF, EF(STE)架构注意事项、WCF、EF(SET)
【发布时间】：2012-09-05 13:55:51
【问题描述】：

我有从 EF 公开 STE 的 WCF 服务。

[OperationContract, FaultContract(typeof(WarningFault)),  FaultContract(typeof(ErrorFault))]
    MyEntity GetMyEntityByID(int id);

    [OperationContract, FaultContract(typeof(WarningFault)), FaultContract(typeof(ErrorFault))]
    MyEntity SaveMyEntity(MyEntity myEntity);

场景如下：

客户端从 WCF(GetMyEntityByID) 获取实体
客户对此实体进行一些更改
客户端调用 SaveMyEntity
在 WCF 服务中是附加到上下文并保存到 db 的特定实体。（并且在保存之前还有一些自定义验证工作。）

因为有 STE，这工作得很好..

但我注意到，这并不是一个好的模式。（在 EF 5.0 中，STE 标记为不推荐）

我应该用什么方法来代替这个？如果我理解正确，WCF 数据服务不适合这种工作，因为它们只公开实体。并在客户端管理保存、验证等。

【问题讨论】：

标签： c# wcf entity-framework architecture wcf-data-services

【解决方案1】：

我建议您使用分离的实体。通过主键从数据库重新加载您的对象，并且仅复制您的客户端能够修改的字段。不要在服务之外公开数据库上下文

【讨论】：

有什么原因吗？因为这需要相当多的工作。实体通常并不简单，有很多导航属性等。在我看来，这种“重新加载对象”是昂贵的操作，使用 STE 可以避免。有什么我看不到的吗？
@Chatumbabub：怎么样：关注点分离、适当的层抽象、单一职责原则、适当的领域模型
@Chatumbabub 我能想到一些原因。首先，您需要在客户端和服务器之间共享程序集（据我所知，STEs over WCF。检查这个答案stackoverflow.com/a/5463866/624680）。其次，如果您的客户的技术发生变化，您将只能将服务限制为 WCF，并失去灵活性。第三，您实际上将您的实体的完全控制权交给了客户。它将完全有权更改您的实体的任何属性和/或下面相关实体的图表。当然，如果你的场景很简单，那就去试试吧。