我正在研究OData，它非常强大，但同时又非常令人不安。这相当于将数据源公开给远程用户。没有任何服务，什么也没有，注入(inject)点也很少，导致几乎可笑的 2 层架构。
我担心的是:
在使用 OData 时很难强制实现 DDD 等模式。
针对一组 soa 数据传输对象使用 OData 也很困难，因为这些对象通常不可查询。即，当您获取 DTO 时，数据库查询已完成，但 OData 才刚刚启动。查询它并没有多大值(value)，因为 DTO 已经在内存中了。
我可以在数据库本身上创建一个 View ，它是 OData 实体的表示，但这会将 UI 问题置于持久性中。大禁忌。
现在，最好的情况是使用笨拙的 javascipt 在 UI 层组合来自各种 DDD 服务的结果集 - 这是维护的噩梦，可重用性记录很差。
另一种可能性是为 OData 实体编写一个转换器，该实体可能是 ViewModel 级别的类，然后转换为 DTO，然后转换为域，然后转换为 ConceptualModel，其余的 ORM 可以处理。但这需要大量的资源。
简而言之，如何使 OData 与 SOA、OO 封装原则、DDD 和旧式 SOC 良好配合？
最佳答案
需要明确区分 OData 标准和 OData 实现。
关于标准:
在我看来，该标准本身可以让您以可移植的方式拥有一个具有完整元数据的 OOTB 可访问数据端点。通过对关系和投影的支持，消费者可以在服务器上或稍后在客户端上构建 View 模型。需要注意的是，OData 支持公开操作(函数)，因此在自动增删改查的基础上，您可以拥有无缝集成到关系模式中的远程方法(函数可以具有您可以进一步查询的结果，仍然在服务器，并且函数也可以充当“智能编写器”代码)。
总而言之:OData 描述了当有人需要大规模 REST 兼容数据访问时实际发生的情况:形式化常见的、总是重复的场景，例如如何查询数据或提交回数据。这可能仍然受到您在第 4 点所写内容的影响，但在我看来，这不是 OData 相关问题。这就是 AJAX 和 Mashups 的工作原理:您将拥有一个包含大量处理组合数据的代码的客户端。
您的其他问题可以通过选择最合适的服务器实现来解决。已经有几个实现:
EF4/EF5 + WCF 数据服务是最“自动”的。在此用例中，您的一些担忧可能是正确的，但是:借助 EF 的精细可扩展性模型，您可以根据需要与自动操作进行交互。拥有由实际 EDMX 模型驱动的应用程序是真正的 DDD 场景。
ASP.NET Web API 让您拥有一个完全基于代码的后端，用于您所认为的静态关系端点，因此您可以在 3 层中进行思考:数据库、中间层数据库数据以及对客户最有利的内容，以及作为该模型的智能消费者的客户端层。
JayData 在服务器端 JavaScript 中提供了这些功能，并增加了 JavaScript 的活力。
SAP NetWeaver 网关以一种易于在简单场景中使用的方式公开复杂的 SAP 数据。
OO 问题:
借助 OData V3，我们现在拥有了“实例方法”(这也绝对是服务器方法)，因此 SOA 通过粗暴地将事物与数据和功能分离而实际上带走了 OData 真正回馈的东西:定义功能 + 封装但映射到 SOA 概念的数据具有上下文数据的静态方法，其行为类似于 "this"。
2Tier 问题: 恕我直言，2Tier 架构变得“古老”，并不是因为客户端对服务器端结构有太多了解，而是因为它们不能很好地扩展，而且新的瘦客户端太笨，无法像真正的数据库客户端一样运行。事实上，2tier 总是更容易使用(从开发人员的角度来看)，现在实际上 OData 服务器实现确实是具有逻辑的中间层，您实际上可以两全其美: - 针对虚拟 2 层架构进行编码 - 并可像普通的 n 层应用程序一样进行扩展。
关于wcf - OData 是否违反关注点分离？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/13062362/