4

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

我的担忧是：

  1. 使用 OData 时很难强制执行 DDD 等模式。

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

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

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

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

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

4

1 回答 1

3

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

至于标准：

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

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

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

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

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

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

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

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

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

于 2012-10-25T08:58:22.153 回答