将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数据服务一样自动化很多东西。带有OData扩展的ASP.NET Web API位于中间，其值并未得到普遍认同（在服务API上使用某些OData URI语法位置肯定是有用的。）

最近围绕ASP.NET Web API的讨论不要太夸张，它和WCF数据服务是非常不同的野兽，并且在你的设计中的不同层上运行。实际上，在多层体系结构中，您可以很好地看到使用ASP.NET Web API构建的服务API位于使用WCF数据服务构建的OData API之上。

我的建议是仔细考虑您正在尝试构建的内容，并根据答案选择ASP.NET Web API并接受以下事实：您公开的API与以数据为中心的OData API非常不同，或坚持使用WCF数据服务。

可能的计划

您可以通过搜索“非CRUD网络/ RESTful /超媒体API”等术语，或通过比较ServiceStack等倡导较少数据的产品，在网上找到有关网络服务层API的大量资料。面向API。

如果您仍然不确定项目的性质，原型。

• 如果您最终得到一堆基本相同的Web API控制器，每个控制器只映射到一个实体，那么您的API就是大量面向数据的。 使用WCF数据服务。
• 如果您最终使用WCF数据服务的许多OData操作和笨拙的实体，那么您需要在API的服务器端提供更多的域逻辑，而数据导向并不能为您提供足够的。 使用Web API 。这里一个好的经验法则是像处理SQL DBMS中的存储过程一样处理OData操作。实际上，将任何OData服务器视为DBMS，因为它们就是这样。 如果你不把它放在SQL接口后面，不要把它放在OData接口后面。

重要（更新）

2014年3月27日宣布，WCF数据服务由Microsoft discontinued支持ASP.NET Web API。为了处理我在这里公开的“数据层”用例，微软已经表示它计划扩展ASP.NET Web API。一些community efforts也正在进行中。 WCF数据服务也将在某个时候开源，因此新的维护者接管并非不可能，尽管它不确定。