wcf – OData是否违反了关注点？

发布时间：2020-12-16 09:52:17 所属栏目：asp.Net 来源：网络整理

导读：我正在看OData,它非常强大,同时它非常令人不安.它相当于将数据源公开给远程用户.没有任何服务没有nada和非常少的注入点,导致几乎滑稽的2层架构. 我担心的是：使用OData时很难强制执行DDD等模式. 对一组soa数据传输对象使用OData也很困难,因为这些通常不可查

我正在看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方面发挥出色？

解决方法

需要明确分离OData标准和OData实现.

至于标准：

我的视图中的标准本身允许您以可移植的方式获得具有完整元数据的OOTB可访问数据端点.通过支持关系和投影,消费者可以在服务器上或稍后在客户端上构建视图模型.值得注意的是,OData支持要暴露的操作(函数),因此在自动crud的顶部,您可以拥有无??缝集成到关系模式中的远程方法(函数可以具有可以进一步查询的结果,仍然在服务器,以及功能可以充当“智能编写器”代码).

总结一下：OData为大多数人需要大规模REST兼容数据访问时实际发生的事情提供了一个形状：形式化常见的,总是重复的场景,如查询数据或提交数据的方式.这可能仍然受到您在第4点写的内容的影响,但我认为这不是与OData相关的问题.这就是AJAX和Mashups的工作原理：你将拥有一个客户端,其中包含大量处理数据组合的代码.

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

> EF4 / EF5 WCF数据服务是最“自动”的.在这个用例中,您可能只关注一些问题,但是：使用EF的精细可扩展性模型,您可以根据需要与自动操作进行交互.拥有由实际EDMX模型驱动的应用程序是真正的DDD场景.
> ASP.NET Web API让你有一个完全基于代码的后端,你可以认为它是一个静态的关系端点,所以你可以在3层思考：DB,中间层来桥接数据库数据和什么最适合客户,客户层作为该模型的智能消费者.
> JayData在Server Side JavaScript中提供了这些增加的JavaScript动力.
> SAP NetWeaver网关以简单方案易于使用的方式公开复杂的SAP数据.

OO关注：
使用OData的V3,我们现在拥有“实例方法”(这也是服务器方法),所以实际上SOA正在将事物与数据和功能完全分开,而OData确实给出了：定义封装的功能数据但是映射到SOA的概念具有上下文数据的静态方法,其行为类似于“this”.

2级问题：恕我直言2Tier架构变得“古老”不是因为客户端对服务器端结构有太多了解,而是因为它们不能很好地扩展,而新的瘦客户端就像真正的数据库客户端一样愚蠢.实际上2tier总是更容易使用(从开发人员的角度来看),现在实际上OData服务器实现确实是具有逻辑的中间层,你实际上可以获得两全其美： – 代码再次成为一个虚拟的2层架构 – 并作为正常的n层应用程序进行扩展.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!