我真的很喜欢OData(WCF数据服务)。在过去的项目中，我编写了很多 Web 服务，只是为了允许以不同的方式读取我的数据。
OData 为客户提供了极大的灵活性，可以根据需要获取数据。
但是，在今天的讨论中，一位同事指出，我们处理 OData 的方式只不过是为客户端应用程序提供与数据库的连接。
以下是我们如何设置 WCF 数据服务(注意:这是传统方式)
- 为我们的数据库创建 Entity Framework (E)F 数据模型
- 使用 WCF 数据服务发布该模型
- 为 OData Feed 添加安全性
(这是比直接连接到 SQL Server 更好的地方)
我的同事(正确地)指出，我们所有的客户端现在都将耦合到数据库。 (如果表或列被重构，那么客户端也必须改变)
EF 在数据的呈现方式上提供了一定的灵活性，并且可用于隐藏一些不影响客户端应用程序的细微数据库更改。但我发现它的作用非常有限。 (参见 this 帖子的示例)我发现 POCO 模板(虽然可以很好地允许模型和实体分离)也不能提供很大的灵活性。
那么问题来了:我该告诉我的同事什么？如何设置我的 WCF 数据服务，以便它们使用面向业务的契约(就像每个读取操作都使用基于标准 WCF Soap 的服务一样)？
为了清楚起见，让我以不同的方式问这个问题。如何将 EF 与 WCF 数据服务分离。我可以编写自己的契约(Contract)并使用 AutoMapper 在它们之间进行转换。但我不想直接从 EF 转到 OData。
注意:我仍然想使用 EF 作为我的 ORM。滚动我自己的 ORM 并不是一个真正的解决方案......
最佳答案
如果您使用自定义类而不是使用 EF 直接生成的类，您还将更改 WCF 数据服务的提供。这意味着您将不再将 EF 上下文作为通用参数传递给 DataService 基类。如果您有只读服务，这没问题，但一旦您期望客户端进行任何数据修改，您将有很多工作要做。
基于EF上下文的数据服务支持数据修改。所有其他数据服务均使用reflection provider默认情况下，它是只读的，直到您实现 IUpdatable在您的自定义“服务上下文类”上。
数据服务是用于快速创建公开数据的服务的技术。它们与上下文耦合，上下文有责任提供抽象。如果您想要提供快速、简单的服务，您就需要依赖 EF 映射支持的功能。您可以在 EDMX 中进行一些抽象，可以进行投影(DefiningQuery、QueryView)等，但所有这些功能都有一些限制(例如投影是只读的，除非您使用存储过程进行修改)。
数据服务与提供数据库连接不同。有一个非常大的区别——连接数据库只会确保访问和执行权限，但不会确保数据安全。 WCF 数据服务提供数据安全性，因为您可以创建拦截器，将过滤器添加到查询中，以仅检索允许用户查看的数据或检查是否允许他修改数据。这就是你可以告诉你的同事的区别。
在抽象的情况下 - 您是否想要一个快速简单的解决方案？您可以在服务和 ORM 之间注入(inject)抽象层，但您需要实现提到的方法，并且必须对其进行测试。
关于entity-framework - 如何在不耦合到我的数据库结构的情况下设置 OData 和 EF？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/7116804/