我刚看完 John Pappa 的复视训练视频，对所有部分如何组合在一起感到震惊。
当我在消化我学到的东西时，我留下了一个严肃的想法。
由于令人难以置信的轻而易举使数据服务的可查询部分和 CUD 部分成为可能，因此 CUD 部分似乎有太多专有的 webapi 方法签名。它易于使用且功能强大，因为它的简单性非常出色，但我们习惯于发布、放置和删除 CUD 部分的内容。这些单独的 WepApi 方法更适合编码，但它们允许明确声明的逻辑来保存内容。例如，我只进行软删除，因此显式声明的 Delete webapi 函数将允许我将已删除的记录插入到我的审计表中，通过设置 DeletedDate 将记录标记为已删除，然后实际上不删除该记录。有时，根据个人的角色，您想要进行过度发布保护。例如 CreatedDate 可能是实体中的一个属性，但客户端强制/无效更改该属性不应自动更新服务器端的列。或者，作为 ServiceTicket 实体的一部分，指定的服务技术人员永远不能被客户端更新，除非用户具有某些角色。
这些服务器端干预在哪里以及如何在微风中的 SaveChanges 方法中编码？当人们期望像“api”这样的完全 Post/Put/Delete 并且微风只提供像 SaveChanges 这样的单一方法时会发生什么？
最后我假设微风使用专有的 ContextProvider 只是因为 odata 实现还没有进行扩展和选择，对吧？如果并且一旦 wepapi odata 完全实现所有 odata 动词，是否有计划取消该额外层？如果有的话，2012 Update 2 在这方面有什么改变吗？
谢谢