我正在看OData，它非常强大，同时它非常令人不安。它相当于将数据源公开给远程用户。没有任何服务没有nada和非常少的注入点，导致几乎滑稽的2层架构。
我担心的是：
使用OData时很难强制执行DDD等模式。
对一组soa数据传输对象使用OData也很困难，因为这些通常不可查询。即，当您获得DTO时，数据库查询已完成，但OData刚刚启动。查询它没有太多价值，因为DTO已经在内存中。
我可以在DB本身上创建一个视图，它是OData实体的一种表示形式，但这会让UI关注持久化。大禁忌。
最好将各种DDD服务的结果集合在一起，现在使用kludgy javascipt在UI层进行 - 这是一种维护性噩梦，可重复性差的记录很差。
另一种可能性是为OData实体编写一个翻译器，该实体可能是ViewModel级别的类，然后转换为DTO，然后转换为域，然后转换为ConceptualModels，其余的ORM可以处理。但这需要过多的资源。
简而言之，你如何让OData在SOA，OO封装原则，DDD以及刚刚好的旧SOC方面发挥出色？
答案 0 :(得分：3)
需要明确分离OData标准和OData实现。
至于标准：
我的视图中的标准本身允许您以可移植的方式获得具有完整元数据的OOTB可访问数据端点。通过支持关系和投影，消费者可以在服务器上或稍后在客户端上构建视图模型。值得注意的是，OData支持要暴露的操作（函数），因此在自动crud的顶部，您可以拥有无缝集成到关系模式中的远程方法（函数可以具有可以进一步查询的结果，仍然在服务器，还有函数可以充当“智能编写器”代码。）
将其包装起来：OData为大多数人需要大规模REST兼容数据访问时的实际情况提供了一个形状：形式化常见的，总是重复的场景，例如查询数据或提交数据的方式。这可能仍然受到您在第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"。
2级问题： 恕我直言2Tier架构变得“古老”不是因为客户端对服务器端结构有太多了解，而是因为它们不能很好地扩展，而新的瘦客户端就像真正的数据库客户端一样愚蠢。实际上2tier总是更容易使用（从开发人员的角度来看），现在实际上OData服务器实现确实是具有逻辑的中间层，你实际上可以获得两全其美： - 代码再次成为一个虚拟的2层架构 - 并作为正常的n层应用程序进行扩展。