OData 是否违反关注点分离？

Question

我在看 OData，它非常强大，但同时也很令人不安。这相当于将您的数据源暴露给远程用户。没有任何服务，也没有什么注入点，这导致了一个几乎可笑的 2 层架构。

我的担忧是：

1. 在使用 OData 时很难实施 DDD 等模式。

2. 对一组 soa 数据传输对象使用 OData 也很困难，因为这些对象通常不可查询。即，当您获得 DTO 时，数据库查询已完成，但 OData 刚刚启动。查询它没有太多价值，因为 DTO 已经在内存中。

3. 我可以在 DB 本身上创建一个表示 OData 实体的视图，但这会将 UI 问题置于持久性中。大禁忌。

4. 现在，在 UI 层使用 kludgy javascipt 最多可以组合来自各种 DDD 服务的结果集 - 可重用性记录不佳的维护噩梦。

5. 另一种可能性是为 OData 实体编写一个转换器，它可能是一个 ViewModel 级别的类，然后转换为 DTO，然后转换为域，然后转换为概念模型，其余的 ORM 可以处理。但这需要大量的资源。

简而言之，您如何让 OData 与 SOA、OO 封装原则、DDD 和良好的旧 SOC 相得益彰？

Answer 1

需要明确区分 OData 标准和 OData 实施。

至于标准：

在我看来，标准本身允许您以可移植的方式拥有具有完整元数据的 OOTB 可访问数据端点。通过对关系和投影的支持，消费者可以在服务器上或稍后在客户端上组合视图模型。需要注意的是，OData 支持要公开的操作（函数），因此在自动 crud 的顶部，您可以拥有无​​缝集成到关系模式中的远程方法（函数可以具有您可以进一步查询的结果，仍然在服务器，并且函数也可以充当“智能编写器”代码）。

总结一下：当人们需要大量符合 REST 的数据访问时，OData 为大多数情况下实际发生的情况提供了一个形式：将常见的、总是重复的场景形式化，例如查询数据或提交数据的方式。这可能仍会受到您在第 4 点所写内容的影响，但在我看来，这不是 OData 相关问题。这就是 AJAX 和 Mashups 的工作方式：您将拥有一个客户端，其中包含大量处理组合数据的代码。

您的其他问题可以通过选择最合适的服务器实现来解决。已经有几个实现了：

• EF4/EF5 + WCF 数据服务是最“自动”的。在这个用例中，您可能只是对您的一些担忧是正确的，但是：使用 EF 的精细可扩展性模型，您可以根据需要与自动操作进行交互。拥有由实际 EDMX 模型驱动的应用程序是真正的 DDD 场景。

• ASP.NET Web API 让您拥有一个完全基于代码的后端，用于您认为是静态的关系端点，因此您可以在 3 层中进行思考：DB、中间层在它们之间架起桥梁数据库数据以及对客户最有利的数据，以及作为该模型的智能消费者的客户层。

• JayData 在服务器端 JavaScript 中提供这些，并增加了 JavaScript 的活力。

• SAP NetWeaver 网关以易于在简单场景中使用的方式公开复杂的 SAP 数据。

OO 问题： 使用 OData V3，我们现在有了“实例方法”（肯定也是服务器方法），所以 SOA 将事物粗暴地分离为数据和 OData 真正回馈的功能实际上带走了：定义功能 + 封装但映射到 SOA 概念的数据具有类似于"this" 的上下文数据的静态方法。

2Tier 关注点： 恕我直言，2Tier 架构变得“古老”并不是因为客户端对服务器端结构有太多了解，而是因为它们不能很好地扩展，而且新的瘦客户端就像一个真正的 DB 客户端一样愚蠢。事实上 2tier 总是更容易使用（从开发人员的角度来看），现在 OData 服务器实现确实是具有逻辑的中间层，您实际上可以两全其美： - 对虚拟 2 层架构进行编码 - 并且可以像普通的 n 层应用程序那样扩展。