1 Вопрос: Можно ли вызвать метод действия (из метода действия) и позволить ASP.Net Core вводить параметры [FromQuery]?

вопрос создан в Wed, May 8, 2019 12:00 AM

У меня есть маршрут /my/route?t=something&..., который обрабатывается методом действия, который затем включает t и вызывает соответствующую подпрограмму для выполнения любых задач. Например:

[HttpGet("my/route")]
public IActionResult GetStuff([FromQuery(Name = "t")]string searchType)
{
    switch (searchType)
    {
        case "type1":
            return getStuff_type1();
        case "type2":
            return getStuff_type2();
        default:
            return BadRequest();
    }
}

Однако каждая подпрограмма ожидает другие параметры запроса (некоторые /многие из которых могут различаться в зависимости от потребностей подпрограммы).

Итак, "type1" может принимать параметры запроса "a", "b", "c", "d"; и "type2" могут принимать параметры запроса "v", "w", "x", "y", "z".

Очевидно, я мог бы вытащить все параметры (abcdvwxyz и другие для других типов) в метод основного действия GetStuff и передать их в подпрограммы соответствующим образом, но это громоздко /грязно ... было бы неплохо, если бы я мог как-то вызовите подпрограммы и просто дайте им указать желаемые параметры запроса, чтобы основной GetStuff не заботился об этом (возможно, потребуется использовать некоторые функциональные возможности ASP.Net Core IoC для выполнения параметров подпрограммы [FromQuery]).

Другой вариант - подпрограммы просто используют Request.Query, чтобы получить их нужные параметры, но это не объявляет /не документирует входные значения для подпрограммы - что не так хорошо для тестирования или ясности кода.

Вопрос в том, имеет ли ASP.Net Core функциональность, позволяющую передавать запрос другому, конкретному методу действия (и выполнять любые необходимые инъекции зависимостей)?

    
0
1 ответ                              1                         

Просто нет. Тем не менее, все параметры действий являются необязательными (они будут заполнены значениями по умолчанию, если они не предоставлены), поэтому предложенный метод простого принятия всех параметров, вероятно, является лучшим выбором. Если это неприемлемо, вы можете вернуться к получению их вручную из Request.Query, но вам нужно будет выполнить свою собственную проверку /привязку с этим (все они будут просто строками).

Тем не менее, исходя из описания вашей проблемы, вам лучше всего использовать отдельные маршруты. По сути, вы немного боретесь с тем, как отображение ресурсов запросов должно работать с HTTP. Если у вас есть разные типы поиска, каждый из которых требует разных параметров, то каждый из них может рассматриваться как уникальный ресурс. Каждый делает что-то свое и требует разного вклада. Рассмотрим низкоуровневый пример, где вы делали все это непосредственно в модели домена без уровня HTTP. Как именно вы справитесь с логикой? У вас был бы только один метод для обработки всех возможных типов поиска? Возможно нет. Даже если бы вы сделали, как бы вы предоставили параметры в этом случае? Разве вам по-прежнему не нужно разрешать ввод всех возможных параметров?

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

1
2019-05-08 15: 58: 50Z
  1. Да, я согласен, что уникальные маршруты лучше, это было (и остается) моим первым выбором. Я поиграл с разными способами работы (пока выяснял мой дизайн маршрута API) и мне было любопытно, возможна ли рассматриваемая функциональность. Спасибо за ответ и поддержку, чтобы придерживаться отдельных маршрутов (хотя я еще не совсем уверен в своей схеме маршрутов ... но это другой вопрос).
    2019-05-08 19: 14: 52Z
источник размещен Вот