asp.net-web-api - 将WCF数据服务OData提供程序转换为Web API的最简单方法是什么？

Question

我目前正在研究将当前的WCF数据服务OData提供程序转换为Web API OData的可行性。

对于Web API的OData实现，我有些困惑。使用WCF数据服务，它位于我们的ADO.Net实体模型的顶部，该实体模型从SQL Server后端公开了一堆表，即，您为WCFDS提供了要生成的ADO模型，然后您可以通过标准访问所有表OData语法。

到目前为止，通过Web API的使用，我们是否为要公开的每个表/对象创建一个控制器或单独的操作？我想念什么吗？ OData Web API控制器是否可以通过ADO Data模型公开整个模型？必须为每个表创建一个动作将是一团糟和过度杀伤力。

当前，如果我们需要添加一个表，我们只需将其映射到EDMX中，WCFDS就会在将其映射到模型的整个上下文时自动公开它。

Answer 1

生成模型
您可以：

使用ASP.NET Web API中的convention model builder。这将生成与EF自己的约定模型生成器生成的模型不同的模型：EdmLib IEdmModel。如果您使用的是模型优先或数据库优先，请参见this question。这种方法似乎确实是倒退了，的确如此，但是大多数情况下都是可行的。
序列化EF模型并将其重建为IEdmModel（请参见this question）。同样，这确实是低效的。如果您使用的是模型优先或数据库优先，则只需反序列化EDMX文件即可构建IEdmModel。它在内部仍会产生不同的模型，但是至少CDSL比CLR代码约定更稳定，因此与使用两个不同的基于约定的模型生成器相比，您所得到的惊喜可能会更少。

原因是ASP.NET Web API OData扩展使用EdmLib，而EF使用其自己的代码和there is no plan to make them work together。如果您好奇的话，也许您会发现this rant有用。
使用API
一旦从唯一的来源生成了模型（以便可以在单个位置上处理模型），则实际上基本上必须为每个实体创建一个控制器。 Web API的目的不是要自动构建事物，而是要为开发人员提供灵活性。 EntitySetController有助于减少冗余，但不能提供所有现成的功能。
退后一步
在上面提到的内容中，我还谈到了服务层API和数据层API之间的区别。 ASP.NET Web API更适合服务，而OData使服务尴尬。另一方面，OData使数据访问变得轻而易举（本质上就像是RESTful SQL），并且由于直接连接到数据模型，因此可以自动化许多事情，就像使用WCF Data Services看到的那样。带有OData扩展名的ASP.NET Web API位于中间，并且其值并未得到普遍同意（尽管在服务API上使用OData URI语法的某些位当然很有用）。
不要被最近围绕ASP.NET Web API的嗡嗡声所吸引，它与WCF数据服务是完全不同的野兽，它们可以在设计中的不同层上运行。确实，在多层体系结构中，您很可能会看到使用ASP.NET Web API构建的服务API位于使用WCF Data Services构建的OData API之上。
我的建议是仔细考虑您要构建的内容，并根据答案选择ASP.NET Web API并接受您公开的API与以数据为中心的OData API完全不同的事实，或者坚持使用使用WCF数据服务。
可能的计划
通过搜索诸如“非CRUD Web / RESTful /超媒体API”之类的术语，或者通过比较诸如ServiceStack之类的产品（它们倡导较少面向数据的API），您可以在Web上找到许多有关服务层API的材料。
如果您仍然不确定项目的性质，请对其进行原型设计。

如果最终得到了一堆与Web API基本上相同的控制器，每个控制器都映射到一个实体，那么您的API就是高度面向数据的。使用WCF数据服务。
如果最终使用WCF数据服务获得了许多OData操作和笨拙的实体，那么您需要在API的服务器端使用更多的域逻辑，并且数据定向无法为您提供足够的服务。使用Web API。一个好的经验法则是对待OData操作，就像对待SQL DBMS中的存储过程一样。实际上，将任何OData服务器都视为DBMS，因为这就是它们。如果您不将其放在SQL接口之后，请不要将其放在OData接口之后。

重要（更新）
2014年3月27日，微软宣布WCF数据服务将被discontinued取代ASP.NET Web API。为了处理我在此处公开的“数据层”用例，微软表示已计划扩展ASP.NET Web API。一些community efforts也正在进行中。 WCF数据服务也将在某个时候开源，因此尽管不确定，新的维护者并非没有可能接任。