OData违反了关注点分离原则吗？

Question

OData违反了关注点分离原则吗？

4

我正在研究 OData，它非常强大，但同时也让人感到不安。这相当于向远程用户公开您的数据源。除了几乎毫无注入点之外，没有服务、什么都没有，结果是一个近乎荒谬的两层架构。

我的担忧有：

1. 使用 OData 很难强制实施 DDD 等模式。 2. 用 OData 对一组 SOA 数据传输对象进行操作也很困难，因为这些对象通常不可查询。也就是说，在获取 DTO 后，数据库查询已经完成，但 OData 刚刚启动。根据它进行查询并没有多少价值，因为 DTO 已经在内存中了。 3. 我可以在数据库本身上创建一个视图，作为 OData 实体的表示，但这会将 UI 关注点放在持久化中。这是一个大忌。 4. 最好的方法是使用笨拙的 JavaScript 在 UI 层合并来自各种 DDD 服务的结果集——这是一个维护噩梦，重用记录很差。 5. 另一个可能性是编写一个 OData 实体的转换器（可能是 ViewModel 级别的类），然后将其转换为 DTO，再将其转换为域，然后转换为概念模型，ORM 可以处理其余部分。但这将需要大量资源。

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

- Alwyn

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Peter Aron Zentai · Accepted Answer

需要清晰地区分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在Server Side JavaScript中提供了这些内容，同时具有JavaScript的动态性。 - SAP NetWeaver网关以易于为简单场景消费的方式公开复杂的SAP数据。

OO问题：

随着OData V3现在拥有“实例方法”（绝对也是服务器方法），因此实际上SOA通过将事物残酷地分离到数据和功能方面所带走的东西，OData确实给出了：定义功能+封装的数据，但映射到像具有上下文数据的静态方法的SOA概念的“this”。

2Tier问题：

在我看来，2Tier体系结构变得“古老”不是因为客户端对服务器端结构有太多了解，而是因为它们不具备良好的可扩展性，并且新的薄客户端太笨以像真正的DB客户端一样运行。实际上，从开发人员的角度来看，2tier始终更易于使用，并且现在实际上OData服务器实现确实是具有逻辑的中间层，因此您实际上可以获得两全其美的最佳选择：

- 再次针对虚拟2层体系结构编写代码 - 并像正常的n层应用程序一样进行缩放。