0

我确信这已经在其他地方得到了回答，但我似乎无法在任何地方找到明确的帖子。

大多数有关分层路由的帖子都讨论了何时需要在 Url 中使用无限数量的令牌。我的问题更多地涉及给定实体在没有与另一个实体的上下文关联的情况下存在没有意义的情况。

例如，我有一个 Contract 实体以及预期的 Contract 控制器。它具有索引、编辑、创建等标准操作。我的网址看起来像

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

现在假设 I Order 实体必须与给定的合同相关联。使用（几乎）默认路由，我将拥有的 Urls

/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

我当然可以保留几乎默认的路由，同时对其进行调整以支持合同号和订单号等附加参数。

或者我可以更改我的路由以显示 Orders 位于层次结构中的 Contracts 之下。在我看来，我有几条路要走：

1) 有一个控制器来处理合同和订单以及用于将操作映射到方法的大量自定义路由。这给了我沿线的网址

/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

虽然我无法想象只有一个控制器有什么好的论据，但我猜这个好东西也可以分成一个合同控制器和一个带有适当路由的订单控制器。

需要注意的要点是合同编号即将出现在 URL 的末尾。

2）另一种选择是单独的控制器，但具有以下网址。这对我来说似乎更自然（合乎逻辑）。

/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 中的合同标记之后，订单编号接近末尾。我发现了一些问题/疑虑

  • 如何处理跨越所有合约的订单数据。如您所见，使用特殊的“All”令牌处理了该问题。

  • 我对 URL 的合同部分使用什么操作。默认情况下，Mvc 中的路由是 /{controller}/{action}/{id}。

3）我看到的第三个选项（但不了解评估优缺点）是使用 RESTful API。我相信这将（可以？？）解决我的第二个担忧，即在处理订单时对合同使用什么操作。基本思想是该操作被替换为 HTTP 动词，如 DELETE 或 PUT，只需要应用于 URL 末尾的实体。

在这种情况下，我最终会得到类似的东西

GET /Contracts/ ' 映射到 Contract 控制器中的 Index 操作 POST /Contracts/Create/ ' 映射到 Contract 控制器中的 Create 操作 GET /Contracts/87Y5r3/Orders/ ' 映射到 Order 控制器中的 Index 操作 PUT /Contracts/87Y5r3 /Orders/45 ' 映射到 Order 控制器中的 Edit 动作 GET /Contracts/All/Orders/ ' 映射到 Order 控制器中的 Index 动作

虽然 RESTful 可能是要走的路，但我对它的了解肯定不够，我最初的反应是它增加了复杂性和限制（有多少动词？？？），这可能会限制它的用处。

根据我的快速阅读，采用 RESTful 方法（包括下面@Robotsushi 建议的 ASP.NET Web API）并不能真正回答我的问题。如果我的页面通过 AJAX 和 JSON 请求数据，则似乎需要考虑 RESTful。从这个意义上说（仅请求数据），它提供了一种处理 Urls 的方法。但是，我的问题更多地集中在标准 MVC 模型上，其中操作将模型传递给视图。归根结底，我仍然需要向我的用户展示网页......

我总结清楚了吗？我还缺少任何其他策略吗？这必须是一个相当普遍的情况，所以我很惊讶我没有找到大量的文章。

我稍微简化了示例，但在我的情况下，我实际上需要将其提升到第三层——合同/订单/项目。

谢谢

4

1 回答 1

-1

这纯粹是我的意见。

我建议您使用网络服务。如果不能，您仍然可以使用 HTTP POST。发送复杂的数据结构会更容易，而不会用大量非结构化的键/值对使 URL 混乱。

如果您使用此策略，您将能够发送 XML 或 JSON 作为您的数据结构，并获得您可能需要的复杂实体表示。

如果您不熟悉基于 HTTP 的 Web 服务，请查看ASP.NET Web API。

祝你好运

编辑 您可以 HTTP POST 数据到您的 MVC 控制器。如果您这样做，那么您可以使用复杂的序列化格式（例如 XML 或 JSON）来发送您的数据。这将允许您的实体需要的分层嵌套。

我应该更清楚地了解 Web 服务。您正在执行的操作类型似乎在 Web 服务中可能会更好。但是，无论您是否选择使用 Web 服务，您的 mvc 控制器都可以使用 HTTP POST 操作正确表示数据。

我希望这有帮助。

于 2012-10-16T03:32:10.060 回答