我非常喜欢OData（WCF数据服务）。在过去的项目中，我编写了许多Web服务，只是为了允许不同的方式来读取我的数据。
OData为客户提供了极大的灵活性，可以根据需要提供数据。
然而，在今天的讨论中，一位同事指出我们如何做OData只不过是为客户端应用程序提供与数据库的连接。
以下是我们如何设置WCF数据服务（注意：这是传统方式）
我的同事（正确地）指出我们所有的客户现在都会加入数据库。 （如果表或列被重构，则客户端也必须更改）
EF为您的数据呈现方式提供了一些灵活性，可用于隐藏一些不会影响客户端应用程序的次要数据库更改。但我发现它非常有限。 （参见this帖子中的示例）我发现POCO模板（虽然很好地允许模型和实体分离）也没有提供很大的灵活性。
所以，问题是：我该怎么告诉我的同事？如何设置我的WCF数据服务，以便他们使用面向业务的合同（就像每次读取操作使用标准的基于WCF Soap的服务一样）？
为了清楚起见，让我以不同的方式问这个问题。如何将EF与WCF数据服务分离。我可以编写自己的合同并使用AutoMapper在它们之间进行转换。但我不想直接从EF到OData。
注意：我仍然希望使用EF作为我的ORM。滚动我自己的ORM并不是一个真正的解决方案...
答案 0 :(得分：3)
如果使用自定义类而不是使用EF直接生成的类，则还将更改WCF数据服务的提供。这意味着您将不再将EF上下文作为通用参数传递给DataService基类。如果您只读服务，那就没关系，但是一旦您希望客户对数据进行任何修改，您就会有很多工作要做。
基于EF上下文的数据服务支持数据修改。所有其他数据服务都使用reflection provider，默认情况下只读，直到您在自定义“服务上下文类”上实现IUpdatable。
数据服务是用于快速创建公开数据的服务的技术。它们与它们的上下文相结合，上下文的责任是提供抽象。如果您想快速轻松地完成服务，则需要依赖EF映射支持的功能。您可以在EDMX中进行一些抽象，您可以进行投影（DefiningQuery，QueryView）等，但所有这些功能都有一些限制（例如，除非您使用存储过程进行修改，否则只能进行投影）。
数据服务与提供与数据库的连接不同。存在一个非常大的区别 - 与数据库的连接将仅确保访问和执行权限，但不会确保数据安全性。 WCF数据服务提供数据安全性，因为您可以创建拦截器，该拦截器将向查询添加过滤器以仅检索允许用户查看的数据或检查是否允许他修改数据。这是你可以告诉你的同事的差异。
如果是抽象 - 你想要一个快速简单的解决方案吗？您可以在服务和ORM之间注入抽象层，但是您需要实现所提到的方法，并且必须对其进行测试。
答案 1 :(得分：1)
最简单的方法：
不要发表您的表格;）
视图与表格分离，因此可以单独简化和重构。
标准方法，也用于报告。
答案 2 :(得分：0)
除了实现更细粒度的数据授权（基于某些字段值等）之外，OData还允许使用OAuth通过Http等开放标准（如JSON / Xml）访问您的数据。这对于Web /移动应用程序非常有用。现在，您可以创建一个Web服务来公开您的数据，但是每当您的客户需要更改数据要求时（例如需要额外的字段），这将保证更改，而OData允许通过OData查询。在大型企业中，这对于在基础架构级别设计安全性也很有用，因为它只允许通过网络防火墙检查/验证安全威胁的基于文本的（http）调用。
答案 3 :(得分：0)
您的OData客户端还有其他一些选项。看看本文中描述的Simple.OData.Client：http://www.codeproject.com/Articles/686240/reasons-to-consume-OData-feeds-using-Simple-ODa
如果你熟悉Simple.Data microORM，它有一个OData适配器： https://github.com/simplefx/Simple.OData/wiki
更新。我的建议是针对客户选择，而您的问题是关于设置服务器端。当然，他们不是你要问的。我会留下我的答案，以便您了解客户的替代方案。