WCF 中 EF 导航属性的最佳实践

Question

根据 .NET 的当前状态，完成以下任务的建议模式和/或技术是什么？

我想通过 WCF 服务传播我的 EF 生成的 SQL 数据库模型。我不想关闭 EF 中的延迟加载，因为我不希望分层结构化实体的级联加载。

在客户端，我不能像处理真正的 EF 对象而不是 WCF 代理一样访问导航属性。我不想发送包括上下文对象在内的 EF 对象，因为在我看来这会破坏 SOA 模式。

事实上，我想更改 Visual Studio 生成的 Reference.cs 文件的实现，以便每次对导航属性的访问都会在需要时引发对服务层的异步回调。

示例：这是一个 Company 类，它通过导航属性引用强制项。这是默认的 WCF-proxy-technique 给我的：

    [System.Runtime.Serialization.DataMemberAttribute()]
    public AddressManager.CompanyService.Mandatory Mandatory {
        get {
            return this.MandatoryField;
        }
        set {
            if ((object.ReferenceEquals(this.MandatoryField, value) != true)) {
                this.MandatoryField = value;
                this.RaisePropertyChanged("Mandatory");
            }
        }
    }

这就是我想要的：

    [System.Runtime.Serialization.DataMemberAttribute()]
    public AddressManager.CompanyService.Mandatory Mandatory {
        get {
            if (this.MandatoryField == null)
            {
                // RAISE SERVICE-METHOD HERE
            }
            return this.MandatoryField;
        }
        set {
            if ((object.ReferenceEquals(this.MandatoryField, value) != true)) {
                this.MandatoryField = value;
                this.RaisePropertyChanged("Mandatory");
            }
        }
    }

Answer 1

这不是一个好方法。

• 您在谈论 SOA，同时您将违反以前的 SOA 原则之一 - 边界是明确的。这意味着您不应隐藏对属性 getter 的任何远程调用。显式意味着开发人员必须看到，如果他想要额外的数据，他必须调用代理上的方法，它将创建比本地调用慢 1000 倍的远程调用。属性获取器中没有隐藏的远程调用。您设计的实际上是 WCF 上的延迟加载，这是您应该避免的。
• 大多数分布式系统的主要目标之一是减少往返，因此为每个导航属性创建往返可能是不好的方法。如果您正在创建需要加载多个相关实体的客户端代码，最好的方法是特殊服务操作，它将在一次往返中返回所有这些实体。仅当加载相关实体稍后发生在与加载初始实体的操作无关的另一个客户端操作期间，多次往返才有意义。
• 请勿触摸 Reference.cs - 生成的代码和生成的代码不应手动修改，因为一旦您对服务和更新代理进行任何单一更改，您的修改就会丢失。

Answer 2

Jeff 告诉我使用 OData，它对我有用。谢谢！