我有一个相当大的数据模型,我想使用 OData V4 协议使用 Web API OData 来公开该模型。
底层数据存储在 SQL Server 2012 数据库中。该数据库中有许多日期时间列。
当我连接它时,我收到一个错误,指出不支持 System.DateTime。
所以这是我的问题,我该怎么做才能在 OData feed 中看到我的 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 模型才能工作。如果可以避免的话,我宁愿不必单独更新数百个属性。
Update:这个问题让我意识到微软在管理其OData产品的方式上存在着深刻的缺陷。问题有很多,但最突出的就是这个。 Web API OData 中缺少大量功能。交易 http://www.getbreezenow.com/documentation/odata-server and 插入件的排序 http://www.getbreezenow.com/documentation/odata-server成为他们中的两个。这两项(在 OData 规范中以及在 Microsoft 终止之前在 WCF 数据服务中)对于任何实际系统都至关重要。
但他们并没有将时间花在 OData 规范中缺少功能的关键点上,而是决定将时间花在删除对许多开发人员非常有帮助的功能上。
它集中体现了糟糕的管理,优先删除工作功能而不是添加急需的功能。
我尝试与 Web API OData 代表讨论这些问题,最后,我打开了一个问题/票证,几天后就关闭了。这就是他们愿意做的事情的结束。
正如我所说,Web API OData 的管理还有很多问题(与 DateTime 无关,因此我不会在这里列出)。我一直是 OData 的坚定支持者,但 Web API OData 管理的明显问题迫使我和我的团队/公司放弃它。
幸运的是,普通的 Web API 可以设置为使用 OData 语法。设置控制器需要更多工作,但最终效果很好。并且它支持日期时间。 (而且管理层似乎至少可以避免做出极其糟糕的决定。)