战略层次MVC路由 [英] Strategy for Hierarchical MVC Routing

问题描述

我相信这已经回答了其他地方，但我似乎无法在别处找到一个明确的帖子。

I am sure this has been answered somewhere else but I cannot seem to find a definitive posting anywhere.

对于大多数有关，当你想在URL标记无限数量的分层路由会谈贴子。我的问题涉及更多的时候是没有道理对于一个给定的实体，以不存在的另一个实体的上下文中有关。

Most of the postings regarding hierarchical routing talks about when you want an unlimited number of tokens in the Url. My question deals more with when it does not make sense for a given Entity to exists without being associated in the context of another Entity.

例如，我有一个预期的合同控制器沿合同的实体。它有标准的操作，如指数，编辑，创建等。我的网址看起来像

For example, I have a Contract entity along with the expected Contract controller. It has the standard Actions like Index, Edit, Create, and so on. My Urls look like

/Contracts/                   ' list all contracts
/Contracts/Create/            ' display form to create new contract
/Contracts/Edit/87Y5r3/       ' display form to edit contract 87Y5r3

现在想象，我命令必须与给定合同关联实体。使用（几乎）默认的路由我会的网址

Now imagine that I Order entity that must be associated with a given Contract. Using the (almost) default routing I would have Urls of

/Orders/                          ' display all orders across all contracts
/Orders/Index/87Y5r3              ' display all orders for contract 87Y5r3
/Orders/Create/87Y5r3             ' display form to create new order for contract 87Y5r3
/Orders/Edit/87Y5r3/45            ' display form to edit order 45 under contract 87Y5r3

我当然可以离开几乎默认的路由，而调整它支持类似的合同号和订单号的附加参数。

I can of course leave the almost default routing while tweaking it to support the additional parameters like contract number and order number.

或者，我可以改变我的路由，表明订单来下层次结构中的合同。在我看来，我有几个途径追求：

Or I can change my routing to show that Orders comes under Contracts in the hierarchy. As I see it, I have several paths to pursue:

1）有一个单独的控制器，与映射行动方法众多定制路线沿同时处理合同和订单。这给了我沿

1) Have a single controller that handles both Contracts and Orders along with numerous custom routes for mapping actions to methods. This gives me Urls along the lines of

/Contracts/                        ' maps to Index action in the Contract controller
/Contracts/Create/                 ' maps to Create action in the Contract controller
/Contracts/Orders/                 ' maps to IndexOrders action in the Contract controller
/Contracts/Orders/Index/87Y5r3     ' maps to IndexOrders action in the Contract controller
/Contracts/Orders/Edit/87Y5r3/45   ' maps to EditOrders action in the Contract controller

虽然我不能想象有只是一个单一的控制器的任何好的说法，我猜测这个好还可以分成合同控制器和一条合适的路由（S）的订单控制器。

While I cannot imagine any good argument for having just a single controller, I am guessing that this good also be split into a Contracts controller and an Orders controller with an appropriate route(s).

要采取的主要观点是，合同编号朝网址的结尾来了。

The main point to take in is that the Contract Number is coming towards the end of the Url.

2）另一种选择是独立的控制器，但与以下网址。这似乎多一点自然的（逻辑）给我。

2) Another option is the separate controllers but with the following Urls. This seems a bit more natural (logical) to me.

/Contracts/                              ' maps to Index action in the Contract controller
/Contracts/Create/                       ' maps to Create action in the Contract controller
/Contracts/?????/87Y5r3/Orders/Index/    ' maps to Index action in the Order controller
/Contracts/?????/87Y5r3/Orders/Edit/45   ' maps to Edit action in the Order controller
/Contracts/?????/All/Orders/             ' maps to Index action in the Order controller

在这种情况下，合同编号来在URL合同令牌与订单号接近尾声到来之后。我已经确定了几个问题/关注

In this case the contract number comes after the Contract token in the Url with the order number coming towards the end. I have identified a few issues/concerns

• 如何处理跨所有合约的推移订单数据。如你所见，处理与一个特殊的全部的标记。

• How to handle Order data that goes across all Contracts. As you can see handled that with a special "All" token.

什么样的​​行动做我使用的URL的合同部分。默认情况下，在MVC中路由/ {控制器} / {行动} / {显示}。

What action do I use for the Contracts portion of the Url. By default, routing in Mvc is /{controller}/{action}/{id}.

3）<击>我已经看到张贴（但不明白不足以评估利弊）第三个选择是使用基于REST的API。我相信，这将（可能？）解决我什么行动，令工作时使用的合同第二个问题。其基本思路是，该诉讼被替换像DELETE或PUT这将只需要在URL的末尾应用到实体的HTTP动词。

3) The third option I have seen posted (but do not understand enough to evaluate pros and cons) is to use RESTful API. I believe this would (could ??) resolve my second concern about what action to use for the Contract when working with Orders. The basic idea is that the action is replaced with an HTTP verb like DELETE or PUT which would only need to apply to the entity at the end of the Url.

在这种情况下，我最终会与像

In this case I would end up with something like

GET /合同/'映射到指数在行动合同控制器
POST /合同/创建/'映射到创建合同控制器动作
GET /合同/ 87Y5r3 /订单/'映射到指数在行动订单控制器
PUT /合同/ 87Y5r3 /订单/ 45'的地图编辑行动订单控制器
GET /合同/全部/订单/'映射到Index操作在订单控制器

GET /Contracts/ ' maps to Index action in the Contract controller POST /Contracts/Create/ ' maps to Create action in the Contract controller GET /Contracts/87Y5r3/Orders/ ' maps to Index action in the Order controller PUT /Contracts/87Y5r3/Orders/45 ' maps to Edit action in the Order controller GET /Contracts/All/Orders/ ' maps to Index action in the Order controller

虽然REST风格可能会去我的方式绝对不足够了解它和我最初的反应是，它增加了复杂性和局限性（多少动词有???）可能会限制其实用性。

While RESTful may be the way to go I definitely do not know enough about it and my initial reaction is that it adds complexity and limitations (how many verbs are there???) that may limit its usefulness.

根据我的快速阅读，具有RESTful方法（包括如下面@Robotsushi建议的ASP.NET Web API）会并没有真正回答我的问题。 REST风格似乎有什么东西，如果我的页面被请求通过AJAX和JSON数据加以考虑。在这个意义上（仅适用于请求数据），它提供了一个方法的URL。不过，我的问题更集中在那里的行动传递一个模型视图标准的MVC模式。在一天结束时，我还需要present网页，我的用户...

Based on my quick reading, going with a RESTful approach (including ASP.NET Web API as suggested by @Robotsushi below) does not really answer my question. RESTful seems to be something to be considered if my pages were requesting data via AJAX and JSON. In that sense (requesting data only) it provides an approach to Urls. However, my question is focused more on the standard MVC model where the action passes a Model to a View. At the end of the day I still need to present web pages to my users...

难道我总结这件事清楚？任何其他的策略，我很想念？这已经是一个相当常见的场景让我很惊讶我还没有发现大量的文章。

Did I sum this up clearly? Any other strategies that I am missing? This has to be a fairly common scenario so I am surprised I have not found a ton of articles.

我简化了的例子有点但对我来说其实我需要借这个第三级---合同/订单/项目。

I simplified the examples a bit but in my case I actually need to take this to a third level --- Contracts / Orders / Projects.

感谢

推荐答案

这纯粹是我的意见。

我会建议你使用Web服务。如果你不能，你仍然可以使用HTTP POST。它会更容易发送复杂的数据结构不与非结构化键/值对很多混乱的URL。

I would recommend that you use a web service. If you can't you can still use HTTP POST. It will be easier to send a complex data structure without cluttering the URL with alot of unstructured key/value pairs.

如果你使用这种策略，你会能够发送XML或JSON作为数据结构，并获得复杂的实体重新presentation你可能需要。

If you used this strategy you would be able to send XML or JSON as your data structure, and get the complex entity representation you probably need.

如果您不熟悉基于HTTP的Web服务，然后检查 ASP。 NET的Web API 。

If you are unfamiliar with HTTP based web services, then check out ASP.NET Web API.

好运

修改
您可以HTTP POST数据到你的MVC控制器。如果你这样做，那么你可以使用一个复杂的序列化格式，如XML或JSON发送您的数据。这将允许为您的实体所需要的分级嵌套。

EDIT You can HTTP POST data to your MVC controller. If you do this then you can use a complex serialization format such as XML or JSON to send up your data. This will allow for the hierarchical nesting that your entities require.

我应该是关于Web服务更加明确。类型要执行的操作看起来他们可能是一个Web服务更好。但是不管你是否选择使用Web服务，你的MVC控制器可以接受的数据可以重新正确$ P $使用HTTP POST操作psented。

I should have been more clear about web services. The type of operations you are performing seem like they might be better off in a web service. However regardless of whether or not you choose to use a web service your mvc controller can accept data can be correctly represented using HTTP POST actions.

我希望这有助于。

这篇关于战略层次MVC路由的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！