处理单数和复数控制器/路由。

I'm a little confused on how I should handle singular and plural routes and controllers in my web application.

我对如何在web应用程序中处理单数和复数路由和控制器感到有点困惑。

The website is a simple quotes site - think Einstein, Shakespeare etc. not Insurance. Within the project I have a controller called `QuoteController'. The controller name is singular, so does this mean that the controller should only handle the display of single quotes? I.E.

这个网站是一个简单的引用网站——想想爱因斯坦，莎士比亚等等，而不是保险。在项目中，我有一个名为“QuoteController”的控制器。控制器名是单数的，这是否意味着控制器只处理单引号的显示?即

/quote/love-is-a-battlefield-1

Do I then need another controller for the display of multiple quotes (plural)? For example:

那么我是否需要另一个控制器来显示多引号(复数)?例如:

/quotes/ (would default to most recent)
/quotes/new
/quotes/shakespeare
/quotes/popular

Is it convention, or good practice, to have separate controllers for singular and plural routes? I hope that makes sense.

对于单数和复数路径，有单独的控制器是一种惯例还是一种好习惯?我希望这说得通。

4 个解决方案

#1

Just because the default controllers of asp-mvc have singular names, it doesn't mean you should implement singular form for all your controllers.

仅仅因为aspx -mvc的默认控制器有单数名，并不意味着您应该为所有的控制器实现单数形式。

The correct answer is: it depends on the quantity of the entity that your controller represents.

正确的答案是:它取决于您的控制器表示的实体的数量。

Singular, example the AccountController is singular because it represents actions (action method) pertaining to a single account only.

例如，AccountController是单数的，因为它只表示与单个帐户相关的操作(操作方法)。

Plural If your controller contains at least one action method that handles multiple entities at a single transaction.

如果您的控制器包含至少一个操作方法，在单个事务中处理多个实体，则使用复数。

Example plural format

复数格式示例

users/update/3

The route above makes you think you are editing all users, which does not makes sense if you read it like a sentence. However, if you read your route like query, it will make much more sense.

上面的路线让你觉得你在编辑所有的用户，如果你像读句子一样读的话，这是没有意义的。但是，如果您像查询一样阅读您的路由，它将更有意义。

If we think about it, a route IS a query: {entities}/{action}/{parameter} looks like a query to me.

如果我们考虑一下，路径是一个查询:{entity}/{action}/{parameter}在我看来就像一个查询。

users/ shorthand of users/all reads "select all users table"

用户/用户的简写/所有的都是“选择所有用户表”

users/123 reads "select single entity from users table"

用户/123读取“从用户表中选择单个实体”

users/update/123 reads "update single entity from users table"

用户/更新/123为“从用户表中更新单个实体”

Major sites use plural format, see sample below

主要网站使用复数格式，请参阅下面的示例

*.com/questions          <- list of questions   (multiple)
*.com/questions/18570158 <- individual question (single)
*.com/questions/ask      <- new question        (single)

*.com/users        <- display list of users (multple)
*.com/users/114403 <- individual user       (single)

asp.net/mvc/tutorials        <- display list of tutorials (multiple) 
asp.net/mvc/tutorials/mvc-5  <- individual tutorial       (single)

facebook.com/messages/     <- Display list of messages (multiple)
facebook.com/messages/new  <- Create a single message  (single)
facebook.com/messages/john <- view individual messages (multiple)

I believe that English grammar should be strictly incorporated in every programming aspect. It reads more natural, and leads to good code hygiene.

我认为英语语法应该严格地融入到编程的各个方面。它读起来更自然，并带来良好的代码卫生。

#2

Answer

Here's a question asked in programmers StackExchange that suggests keeping class names singular. I especially like the logic in one of the answers, "The tool to turn screws with is called "screw driver" not "screws driver"." Which I agree with. The names should be kept to nouns and adjectives.

这是程序员StackExchange中提出的一个问题，建议保持类名的单一性。我特别喜欢其中一个答案中的逻辑，“用来旋转螺丝的工具叫做螺丝刀”而不是“螺丝刀”。我同意。名字应该保留在名词和形容词中。

As far as routing goes, best practices seems to favor that routes be pluralized nouns, and to avoid using verbs. This Apigee blog says, "avoid a mixed model in which you use singular for some resources, plural for others. Being consistent allows developers to predict and guess the method calls as they learn to work with your API." and suggests using singular or plural based off what popular websites have done. Their only example for using singular nouns in the route is the Zappos site, which has http://www.zappos.com/Product as a route; but if you examine the site, it's not exactly a route to a product resource but is instead a query, probably for all their products. You can enter http://www.zappos.com/anything and get a results page. So I wouldn't put too much stock into that.

就路由而言，最佳实践似乎更倾向于使用复数名词路由，避免使用动词。这个Apigee的博客说，“避免一种混合模式，你用单数来表示某些资源，用复数来表示其他资源。”一致性允许开发人员在学习使用API时预测和猜测方法调用。他们在路线中使用单数名词的唯一例子是Zappos网站，该网站有http://www.zappos.com/Product作为路线;但是如果你检查这个站点，它并不是一个产品资源的路径，而是一个查询，可能是针对他们所有的产品。您可以输入http://www.zappos.com/anything并获得一个结果页面。所以我不会太看重这个。

Other blogs like this one from mwaysolutions (random find) say to "use nouns but no verbs" and "use plural nouns". Other points aside, most blogs/articles tend to say the same thing. Plural nouns and no verbs.

其他类似于mwaysolutions (random find)的博客说“使用名词，但不使用动词”和“使用复数名词”。除此之外，大多数博客/文章都倾向于说同样的话。名词复数，不带动词。

TL;DR: Use singular nouns for controllers and plural nouns for routes.

用单数名词表示控制器，用复数名词表示路线。

Controllers

Controllers and routes represent two different concepts. The controller is a class, or a blueprint. Similar to a stamper, I wouldn't say I had a UnicornsStamper I'd say I had a UnicornStamper that makes a stamp of a unicorn with which I could make a collection of unicorn stamps with. Collections, Enum types that are bit fields, static class that is a collection of properties (acts like a collection), and probably a few other edge cases are where I'd use a plural name.

控制器和路由代表两个不同的概念。控制器是一个类或蓝图。就像邮票一样，我不会说我有独角兽邮票，我会说我有独角兽邮票，它可以制作独角兽邮票，我可以用它来收集独角兽邮票。集合、位字段的Enum类型、属性集合的静态类(类似于集合)，以及可能使用复数名称的其他一些边的情况。

Routes

A(n) URL is an address to a resource, thus the name Uniform Resource Locator. I disagree that "a route IS a query". Routes can contain queries (query string) to narrow down returned resources but the route is the location or the resource(s) that's being requested.

一个(n) URL是一个资源的地址，因此名称统一资源定位器。我不同意“路由是查询”。路由可以包含查询(查询字符串)来缩小返回的资源，但是路由是被请求的位置或资源(s)。

With the advent of attribute routing, pluralizing routes for controllers is as easy as adding a [RoutePrefix("quotes")] attribute to the QuoteController declaration. This also allows for easier design for associative routes. Looking at the sample routes provided in the original question:

随着属性路由的出现，控制器的多元化路由就像在QuoteController声明中添加[RoutePrefix(“quotes”))一样简单。这也使得关联路径的设计更加容易。查看原始问题中提供的示例路由:

/quotes GET: Gets all quotes POST: Creates a new quote /authors/shakespeare/quotes Associative route in the QuoteController GET: Gets all Shakespeare quotes /quotes/new This is a bad route IMO. Avoid verbs. Make a POST request to '/api/quotes' to create a new quote /quotes/shakespeare /quotes/popular Although these would be nice to have, they're not practical for routing (see below)

获取所有引用:在QuoteController的GET中创建一个新的引用/author /shakespeare/quotes /quotes的关联路径:获取所有莎士比亚的引用/引用/new这是一条很糟糕的路径。避免动词。向'/api/引号'发出POST请求，以创建新的引用/引号/莎士比亚/引号/流行的引用，尽管有这些很好，但它们不适合路由(参见下面)

The problem with the last two routes is that you have no simple way of differentiating between popular quotes and quotes by authors, not to mention that routes that link to quotes by name or Id. You would need actions decorated with [Route("popular")] followed by [Route("{author}")] (in that order) in order for the routing table to pick the routes up in the appropriate order. But the author route kills the possibility of having routes [Route("{quoteName}")] or [Route("{quoteId}")] (assuming quoteId is a string). Naturally, you'll want to have the ability to route to quotes by name and/or ID.

最后两个路线的问题是,你没有简单的方法区分流行的引用和引用的作者,更不用说路线名称或Id链接引用的。你需要行动装修(路线(“受欢迎的”)]其次是[路线(“{作者}”)](依次)为了使路由表以适当的顺序来接的路线。但是，作者路由选择了路由(“{quoteName}”)或路由(假设quoteId是字符串)的可能性。当然，您希望能够通过名称和/或ID路由到引号。

Slightly Off Topic

Getting quotes by author would best be done by an associative route. You could still probably get away with the popular route as a static route name, but at this point you're increasing route complexity which would be better suited for a query string. Off the top of my head, this is how I might design these routes if I really wanted to have the popular search term in the route:

获得作者的引用最好是通过关联路径。您仍然可以不使用流行的路由作为静态路由名称，但是现在您正在增加路由复杂性，这将更适合于查询字符串。在我的脑海中，如果我真的想在路线中使用流行的搜索词，我可以这样设计这些路线:

a:/authors/{authorName}/quotes b:/authors/{authorName}/quotes/popular c:/authors/{authorName}/quotes?popular=true d:/quotes/popular e:/quotes/popular?author={authorName} f:/quotes?author={authorName}&popular=true g:/quotes/{quoteName|quoteId}

答:/作者/ { authorName } /引用b:/作者/ { authorName } /报价/流行的c:/作者/ { authorName } /报价吗?流行= true d:/引用/流行e:/报价/受欢迎吗?作者= { authorName } f:/报价吗?作者= { authorName }欢迎= true g:/报价/ { quoteName | quoteId }

These could be spread across the QuoteController's actions. Assuming the controller has a [RoutePrefix("quotes")] attribute:

这些操作可以分布在QuoteController的操作中。假设控制器有[RoutePrefix(“quotes”))]属性:

[HttpGet] [Route("popular")] [Route("~/authors/{authorName}/quotes/popular")] // Handles routes b, d, & e public ViewResult GetPopularQuotes(string authorName) return GetQuotes(authorName, true); [HttpGet] [Route("")] [Route("~/authors/{authorName}/quotes") // Handles routes a, c, & f public ViewResult GetQuotes(string authorName, bool popular = false) // TODO: Write logic to get quotes filtered by authorName (if provided) // If popular flag, only include popular quotes [HttpGet] [Route("{quoteId}")] // Handles route g public ViewResult GetQuoteById(string quoteId) // TODO: Write logic to get a single quote by ID

[HttpGet] [Route("popular")] [Route(") ("~/authors/{authorName}/quotes/popular")] //处理路由b、d和e公共ViewResult GetPopularQuotes(string authorName)返回GetQuotes(authorName, true);(" ")][HttpGet][路线(路线(“~ /作者/ { authorName } /引用”)/ /处理路线,c & f公共ViewResult getquote(字符串authorName,bool流行= false)/ / TODO:写逻辑被authorName引用过滤(如果提供)/ /如果受欢迎的旗帜,只包括流行的引用(HttpGet)[路线(“{ quoteId }”)]/ /处理路线g公共ViewResult GetQuoteById(字符串quoteId)/ / TODO:写逻辑通过ID获取单引号

Disclaimer: I wrote these attributes off the top of my head, there may be minor discrepancies that would need to be ironed out, but hopefully the gist how to get these routes to work comes through.

免责声明:我把这些属性写在了我的头顶上，可能会有一些细微的差异需要解决，但我希望能找到这些方法的要点。

Hopefully this helps to clear up some confusion on the topic of controller and routing best practices on naming conventions. Ultimately the decision to use plural or singular controllers or routes is up to the developer. Regardless, be consistent once you pick a best practice to follow.

希望这有助于消除关于controller和路由命名约定的最佳实践的一些混乱。最终决定使用复数或单数控制器或路由取决于开发人员。无论如何，一旦你选择了一个最佳实践，就要坚持下去。

#3

Name of controller can be plural or singular based on the logic it executes. Most likely we keep controller name as singular because ProductController sounds little better than ProductsController.

根据控制器执行的逻辑，控制器的名称可以是复数或单数。最可能的情况是，我们将控制器名保持为单数，因为ProductController听起来并不比ProductsController好多少。

   /product/list    or    /products/list
   /product/add   or    /products/add

You can use both. But you must keep consistency and you should not mix them. Either all URL should be plural for every entity types or all should be singular.

你可以同时使用。但你必须保持一致性，不要混淆它们。每个实体类型的所有URL都应该是复数，或者所有的URL都应该是单数。

In ASP.NET sample, they have used Singular controller names Such as HomeController, AccountController. In case of HomeController you can't use HomesController because that no longer represents current site Home.

在ASP。NET样例，他们使用了单一的控制器名称，如HomeController, AccountController。如果是HomeController，你不能使用HomesController，因为它不再代表当前的网站主页。

With regards to logic, mostly we create Controller per database entity, in which we infer that Controller represents Actions to be performed on "Entity" So it is good to use Singular controller name and there is no harm.

在逻辑方面，我们通常为每个数据库实体创建控制器，其中我们推断控制器表示要在“实体”上执行的操作，所以最好使用单数控制器名，没有任何危害。

Only if you want to create set of Controller representing collection of something that should look like or map to plural database table names then you can name that as plural.

只有当您想要创建一组控制器来表示应该看起来像或映射到复数数据库表名称时，您才可以将其命名为复数。

#4

Good question. Some contributors to this site would recommend you try Programmers website, but I'm willing to attempt an answer to your question.

好问题。这个网站的一些贡献者会推荐你尝试程序员网站，但我愿意尝试回答你的问题。

Routing mechanism in ASP.NET MVC ,conceptually, is based on Resource-oriented architecture; the common guideline in ROA is

路由机制在ASP。NET MVC概念上是基于面向资源的体系结构;ROA的共同准则是。

Applications should expose many URIs (possibly an infinite number of them), one for each Resource (any resources in your applications should be unambiguously accessible via a unique URI)

应用程序应该公开许多URI(可能有无数个URI)，每个资源一个URI(应用程序中的任何资源都应该通过唯一的URI明确地访问)

So, it's up to you to decide whether quote and quotes are two different resources or not.

因此，决定引用和引用是否是两种不同的资源取决于你。