的WebAPI和控制器矫枉过正

我开始的WebAPI &的OData集成到测试平台的应用程序。让我们保持简单并坚持使用一个域名实体Customer。很明显我会有一个MVC控制器。搜索获取它自己的视图模型（基于Lucene索引），所以这将是单独的控制器，现在ODataController。但由于查看/编辑页面将有自己的视图模型，他们将是他们自己的控制器。这开始感觉过度杀伤。的WebAPI和控制器矫枉过正

试图找出一个好的设计，使这项工作，并与代表实体的URL的想法仍然有效。如果URL中的实体是Customer，并且我以某种方式提供基于URL参数的不同表示形式？还是应该客户/ CustomerSearch/CustomerEdit是不同的实体（这听起来不对）？

来源

2013-03-17 Rich

丰富，我目前工作的地方，我们打算使用的OData和Web API的一个项目，但我想让它灵活（likee EF呼叫）。我们不在这个阶段（打算从直接数据库转移到服务）。你正在思考超前曲线。这就是为什么我不认为有人会帮助你。 OData不再是新的，但我不认为许多商店正在使用它。与web API的结合似乎对我来说显而易见，因此我做了一项研究。这里是一些关于从我们的社区实施这样一个解决方案的视频http://www.asp.net/web-api/overview/odata-support-in-aspnet-web-api – 2013-03-18 00:23:15

我假定这的WebAPI应用将是从你要构建ASP.NET MVC解决方案的独立解决方案。简而言之，WebAPI将成为业务/领域层，而MVC将成为表示层。

所以，在解决方案的WebAPI的讲，你只需要你上面介绍的客户例如单ApiController。查看/编辑请求可能有自己的视图模型...或不是。根据您制作视图模型的方式，您可能可以为客户提供单一视图模型，也可以开发客户视图层次结构，其中基础视图模型包含搜索相关数据，而后代视图模型充实细节。

你的路由请求可能看起来像：

GET - /Customer/     retrieve multiple customers 
            (supplying OData parameters in query string) 
GET - /Customer/{id}    retrieve a single customer 
PUT - /Customer/{id}    edit customer

是什么样子的，你需要的是两条路线，一个ApiController的客户，并为你描述哪三个请求方法。我不建议为OData单独使用ApiController，因为功能依赖于实体。

来源

2013-03-18 00:42:12

想过这个之后，我绝对看不使用ODataController，特别是只有Gets将被完成，并且因为它将我锁定到仅适用于一种实体类型的控制器中。我正在使用此路由的变体。 “/ Customer”使用WebApi基础查询功能用于查看模型和编辑模型“/ Customer/View/{id}”+“/ Customer/Edit/{id}”的搜索和操作“ – Rich 2013-03-18 02:32:07

也许我不理解你的方法。您将在WebAPI方面使用操作，而不是HTTP动词？ – 2013-03-18 03:29:37

可能需要两者。问题是，仅用于视图的模型和用于编辑的模型将根据定义而不同。例如，编辑模型可能需要客户可能拥有的可能的角色列表。视图模型显然不会有。但编辑模型将需要GET和PUT/POST。 – Rich 2013-03-18 04:11:37

的WebAPI和控制器矫枉过正

回答

相关问题