我有一个相当大的数据模型,我想使用 OData V4 协议使用 Web API OData 公开它。
基础数据存储在 SQL Server 2012 数据库中。该数据库中有许多 DateTime 列。
当我连接它时,我收到一个错误,即 System.DateTime 不受支持。
所以这是我的问题,我该怎么做才能在 OData 提要中看到我的 DateTime 列?
注意:我无法返回并将所有列更改为 DateTimeOffset 列。
我尝试更改实体框架 edmx 中列的类型,但它给了我这个错误:
指定的成员映射无效。'MyProject.MyEntity' 类型中成员 'MyPropertyHere' 的类型 'Edm.DateTimeOffset[Nullable=False,DefaultValue=,Precision=]' 与 'SqlServer.datetime[Nullable=False,DefaultValue=,Precision=3] 不兼容'MyDataModel.Store.MyEntity' 类型中的成员 'MyColumnName'。
(基本上认为 DateTime 与 DateTimeOffset 不兼容。)
Web API OData 团队真的忽略了所有需要使用 SQL Server 类型的人DateTime
吗?
更新:我找到了解决方法,但它们需要更新 EF 模型才能工作。如果可以避免的话,我宁愿不必单独更新数百个属性。
更新:这个问题让我意识到微软管理其 OData 产品的方式存在严重缺陷。有很多问题,但这个是最明显的。Web API OData 中有大量缺失的功能。 插入的事务和排序是其中的两个。这两个项目(在 OData 规范中并且在微软杀死它之前在 WCF 数据服务中)对于任何实际系统都至关重要。
但是,他们没有将时间花在那些缺少 OData 规范中的功能的关键点上,而是决定花时间删除对许多开发人员非常有帮助的功能。它集中体现了糟糕的管理,优先考虑删除工作功能而不是添加急需的功能。
我尝试与 Web API OData 代表讨论这些问题,最后,我打开了一个问题/票证,几天后又关闭了。这就是他们愿意做的事情的结束。
正如我所说,Web API OData 的管理还有很多问题(与 DateTime 无关,因此我不会在此列出)。 我一直是 OData 的坚定支持者,但 Web API OData 管理的明显问题迫使我和我的团队/公司放弃它。
幸运的是,普通的 Web API 可以设置为使用 OData 语法。设置控制器需要做更多的工作,但最终效果很好。它支持日期时间。(而且似乎拥有至少可以避免做出疯狂错误决定的管理层。)