Эффективный способ внесения параметров в URL-адреса действий контроллера

Здесь есть объяснение, которое, я думаю, вы не понимаете. Запросы GET намеренно упрощены. Они должны описывать конкретный ресурс. У них нет тел, потому что вы не должны передавать сложные объекты данных в первую очередь. Протокол HTTP разработан не так.

Кроме того, параметры строки запроса обычно должны быть необязательными. Если для идентификации ресурса требуется некоторый бит данных, он должен быть частью основного URI (то есть пути). Таким образом, пренебрежение добавлением чего-то вроде параметра query должно просто привести к возврату полного набора данных вместо некоторого подмножества, определенного query. Или, в случае чего-то вроде страницы поиска, это обычно приводит к тому, что пользователю предоставляется форма для сбора query. Другими словами, ваше действие должно учитывать отсутствие этого параметра и соответствующим образом обрабатывать эту ситуацию.

Короче говоря, нет, я полагаю, что нет никакого "элегантного" способа справиться с этим, но причина в том, что этого не должно быть. Если вы правильно проектируете свои маршруты и действия, обычно это не проблема.

Чтобы решить эту проблему, я хотел бы, чтобы объект запроса использовался в качестве параметров маршрута для привязки TagHelper. Это означает, что все ссылки маршрута определены только в одном месте, а не во всем решении. Изменения, внесенные в объектную модель запроса, автоматически распространяются на URL для <a asp-action>-тегов.

Преимущество этого заключается в сокращении количества мест в коде, которые нам нужно изменить при изменении сигнатуры метода для действия контроллера. Мы локализуем изменения только для модели и действия.

Я подумал, что написание тега-помощника для пользовательского asp-object-route может помочь. Я изучал цепочку Taghelpers, чтобы мой мог работать до AnchorTagHelper, но это не работает. Создание экземпляра и их вложение требует, чтобы я жестко закодировал все свойства Ядра ASP.Net AnchorTagHelper, которые могут потребовать обслуживания в будущем. Также рассматривалось использование настраиваемого метода с UrlHelper для создания URL-адреса, но тогда TagHelper не работал.

Решение, на которое я пришел, - использовать asp-all-route-data, как предлагает @ kirk-larkin, вместе с методом расширения для сериализации в Dictionary. Любой asp-all-route-* переопределит значения в asp-all-route-data.

<a asp-controller = "Test" asp-action = "HelloWorld" asp-all-route-data = "@Model.RouteParameters.ToDictionary()" asp-route-somestring = "optional override">Link</a>

ASP.Net Core может десериализовать сложные объекты (включая списки и дочерние объекты). public IActionResult HelloWorld(HelloWorldRequest request) { }

В объекте запроса (при его использовании) обычно есть только несколько простых свойств. Но я подумал, что было бы неплохо, если бы он поддерживал и дочерние объекты. Сериализация объекта в Словаре обычно выполняется с помощью отражения, которое может быть медленным. Я подумал, что Newtonsoft.Json будет более оптимизирован, чем сам писать простой код отражения, и обнаружил, что эта реализация готова к работе:

public static class ExtensionMethods
{

    public static IDictionary ToDictionary(this object metaToken)
    {
        // From https://geeklearning.io/serialize-an-object-to-an-url-encoded-string-in-csharp/
        if (metaToken == null)
        {
            return null;
        }

        JToken token = metaToken as JToken;
        if (token == null)
        {
            return ToDictionary(JObject.FromObject(metaToken));
        }

        if (token.HasValues)
        {
            var contentData = new Dictionary();
            foreach (var child in token.Children().ToList())
            {
                var childContent = child.ToDictionary();
                if (childContent != null)
                {
                    contentData = contentData.Concat(childContent)
                        .ToDictionary(k => k.Key, v => v.Value);
                }
            }

            return contentData;
        }

        var jValue = token as JValue;
        if (jValue?.Value == null)
        {
            return null;
        }

        var value = jValue?.Type == JTokenType.Date ?
            jValue?.ToString("o", CultureInfo.InvariantCulture) :
            jValue?.ToString(CultureInfo.InvariantCulture);

        return new Dictionary { { token.Path, value } };
    }
}

В другом ответе я нашел способ предоставить объект запроса через модель.

Из статьи SO @tseng я нашел меньшее решение. Он не использует объект запроса в модели, но сохраняет все параметры маршрута, если это явно не переопределено. Он не позволит вам указывать маршрут через объект запроса, что в любом случае чаще всего не то, что вам нужно. Но это решило проблему в OP.

<a asp-controller = "Test" asp-action = "HelloWorld" asp-all-route-data = "@Context.GetQueryParameters()" asp-route-somestring = "optional override">Link</a>

Для этого требуется метод расширения для преобразования параметров запроса в словарь.

public static Dictionary GetQueryParameters(this HttpContext context) { return context.Request.Query.ToDictionary(d => d.Key, d => d.Value.ToString()); }