Обработка сингулярных и множественных контроллеров/маршрутов

Ответ 1

Просто потому, что стандартные контроллеры asp-mvc имеют уникальные имена, это не значит, что вы должны внедрять единую форму для всех ваших контроллеров.

Правильный ответ:, это зависит от количества объекта, который представляет ваш контроллер.

Singular, например, AccountController является сингулярным, поскольку он представляет действия (метод действий), относящиеся только к одной учетной записи.

Множественное Если ваш контроллер содержит хотя бы один метод действий, который обрабатывает несколько объектов в одной транзакции.

Пример множественного формата

users/update/3

Вышеупомянутый маршрут заставляет вас думать, что вы редактируете всех пользователей, что не имеет смысла, если вы читаете его как предложение. Однако, если вы прочтете свой маршрут, как запрос, это будет иметь больший смысл.

Если мы думаем об этом, маршрут IS является запросом: {entities}/{action}/{parameter} выглядит как запрос для меня.

users/ сокращенное обозначение users/all читает "выберите всю таблицу пользователей"

users/123 читает "выберите отдельную сущность из таблицы пользователей"

users/update/123 читает "обновить единый объект из таблицы пользователей"

Основные сайты используют множественный формат, см. пример ниже

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

stackoverflow.com/users        <- display list of users (multple)
stackoverflow.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)

Я считаю, что грамматика английского языка должна быть строго учтена в каждом аспекте программирования. Он читает более естественно и ведет к хорошей гигиене кода.

Ответ 2

Ответ

Здесь question спросил у программистов StackExchange, что предполагает сохранение уникальных имен классов. Мне особенно нравится логика в одном из ответов: "Инструмент для поворота винтов называется" отверткой ", а не" винтовым драйвером ". С чем я согласен. Имена должны храниться в существительных и прилагательных.

Что касается маршрутизации, лучшие практики, похоже, благоприятствуют тому, что маршруты являются плюрализуемыми существительными и избегать использования глаголов. Этот Apigee blog говорит: "избегайте смешанной модели, в которой вы используете единицу для некоторых ресурсов, множественное число для других. предсказывать и угадывать вызовы метода, поскольку они учатся работать с вашим API". и предлагает использовать единственное или множественное число, основанное на том, что сделали популярные веб-сайты. Их единственным примером использования единственных существительных в маршруте является сайт Zappos, который http://www.zappos.com/Product в качестве маршрута; но если вы исследуете сайт, это не совсем путь к ресурсу продукта, а скорее запрос, возможно, для всех их продуктов. Вы можете ввести http://www.zappos.com/anything и получить страницу результатов. Поэтому я не стал бы вкладывать в него слишком много акций.

Другие блоги, такие как this один из mwaysolutions (random find) говорят "использовать существительные, но не глаголы" и "использовать множественные существительные". Другие моменты в сторону, большинство блогов/статей, как правило, говорят то же самое. Плюралиальные существительные и глаголы.

TL; DR: Используйте исключительные существительные для контроллеров и множественных существительных для маршрутов.

Контроллеры

Контроллеры и маршруты представляют собой две разные концепции. Контроллер - это класс или план. Подобно шаблону, я бы не сказал, что у меня есть UnicornsStamper Я бы сказал, что у меня есть UnicornStamper, который делает печать единорога, с которым я мог бы сделать коллекцию марок единорога. Коллекции, типы Enum, которые являются битовыми полями, статический класс, который представляет собой набор свойств (действует как коллекция) и, возможно, несколько других случаев с краями, я бы использовал множественное имя.

Маршруты

A (n) URL-адрес - это адрес ресурса, поэтому имя Uniform Resource Locator. Я не согласен, что "маршрут IS запрос". Маршруты могут содержать запросы (строку запроса), чтобы сузить возвращаемые ресурсы, но маршрут - это местоположение или ресурс (ы), который запрашивается.

С появлением маршрутизации атрибутов плюрализующие маршруты для контроллеров так же просто, как добавление атрибута [RoutePrefix("quotes")] к объявлению QuoteController. Это также позволяет упростить проектирование ассоциативных маршрутов. Посмотрите пример маршрутов, заданных в исходном вопросе:

/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)

Проблема с двумя последними маршрутами заключается в том, что у вас нет простого способа дифференцировать популярные цитаты и цитаты авторов, не говоря уже о маршрутах, которые ссылаются на цитаты по имени или идентификатору. Вам потребуются действия, украшенные [Route("popular")], а затем [Route("{author}")] (в указанном порядке), чтобы таблица маршрутизации выбрала маршруты в соответствующем порядке. Но авторский маршрут убивает возможность наличия маршрутов [Route("{quoteName}")] или [Route("{quoteId}")] (предполагая, что quoteId - строка). Естественно, вы захотите иметь возможность маршрутизировать кавычки по имени и/или идентификатору.

Отключенная тема

Получение цитат автором лучше всего было бы путем ассоциативного маршрута. Вероятно, вы, вероятно, избежите популярного маршрута как статического имени маршрута, но на данный момент вы увеличиваете сложность маршрута, который лучше подходит для строки запроса. С моей точки зрения, я мог бы спроектировать эти маршруты, если бы я действительно хотел иметь популярный поисковый запрос на маршруте:

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}

Они могут быть распределены по действиям 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

Отказ от ответственности: Я написал эти атрибуты с верхней части головы, могут быть небольшие несоответствия, которые нужно будет сгладить, но, надеюсь, суть, как получить эти маршруты для работы.

Надеюсь, это поможет устранить некоторую путаницу по теме контроллера и маршрутизации лучших практик в соглашениях об именах. В конечном итоге решение использовать множественные или сингулярные контроллеры или маршруты зависит от разработчика. Независимо от того, будьте последовательны, как только вы выберете наилучшую практику.

Ответ 3

Название контроллера может быть множественным или сингулярным на основе выполняемой логики. Скорее всего, мы держим имя контроллера как единственное, потому что ProductController звучит немного лучше, чем ProductController.

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

Вы можете использовать оба. Но вы должны поддерживать последовательность, и вы не должны смешивать их. Любой URL-адрес должен быть множественным для всех типов сущностей, или все должны быть единственными.

В образце ASP.NET они использовали имена контроллеров Singular, такие как HomeController, AccountController. В случае с HomeController вы не можете использовать HomesController, потому что это больше не представляет текущий сайт Home.

Что касается логики, в основном мы создаем Controller для каждого объекта базы данных, в котором мы делаем вывод о том, что Controller представляет действия, которые должны выполняться над "Entity". Поэтому полезно использовать имя Singular controller, и нет никакого вреда.

Только если вы хотите создать набор контроллеров, представляющих коллекцию того, что должно выглядеть или сопоставляться с именами таблиц множественной базы данных, вы можете назвать это как множественное число.

Ответ 4

Механизм маршрутизации в ASP.NET MVC, концептуально, основан на ресурсо-ориентированная архитектура; общий ориентир в ROA

Приложения должны выставлять много URI (возможно, их бесконечное число), по одному для каждого ресурса (любые ресурсы в ваших приложениях должны быть однозначно доступны через уникальный URI)

Итак, вам решать, будут ли quote и quotes два разных ресурса или нет.