Asp net mvc actionlink

Definition

Overloads

Returns an anchor element (a element) for the specified link text and action.

Returns an anchor element (a element) for the specified link text, action, and route values.

Returns an anchor element (a element) for the specified link text, action, and controller.

Returns an anchor element (a element) for the specified link text, action, and route values as a route value dictionary.

Returns an anchor element (a element) for the specified link text, action, route values, and HTML attributes.

Returns an anchor element (a element) for the specified link text, action, route values as a route value dictionary, and HTML attributes as a dictionary.

Returns an anchor element (a element) for the specified link text, action, controller, route values, and HTML attributes.

Returns an anchor element (a element) for the specified link text, action, controller, route values as a route value dictionary, and HTML attributes as a dictionary.

Returns an anchor element (a element) for the specified link text, action, controller, protocol, host name, URL fragment, route values, and HTML attributes.

Returns an anchor element (a element) for the specified link text, action, controller, protocol, host name, URL fragment, route values as a route value dictionary, and HTML attributes as a dictionary.

ActionLink(HtmlHelper, String, String) ActionLink(HtmlHelper, String, String)

Returns an anchor element (a element) for the specified link text and action.

Parameters

The HTML helper instance that this method extends.

The inner text of the anchor element.

The name of the action.

Returns

An anchor element (a element).

Exceptions

The linkText parameter is null or empty.

ActionLink(HtmlHelper, String, String, Object) ActionLink(HtmlHelper, String, String, Object)

Returns an anchor element (a element) for the specified link text, action, and route values.

Parameters

The HTML helper instance that this method extends.

The inner text of the anchor element.

The name of the action.

An object that contains the parameters for a route. The parameters are retrieved through reflection by examining the properties of the object. The object is typically created by using object initializer syntax.

Returns

An anchor element (a element).

Exceptions

The linkText parameter is null or empty.

ActionLink(HtmlHelper, String, String, String) ActionLink(HtmlHelper, String, String, String)

Returns an anchor element (a element) for the specified link text, action, and controller.

Parameters

The HTML helper instance that this method extends.

The inner text of the anchor element.

The name of the action.

The name of the controller.

Returns

An anchor element (a element).

Exceptions

The linkText parameter is null or empty.

ActionLink(HtmlHelper, String, String, RouteValueDictionary) ActionLink(HtmlHelper, String, String, RouteValueDictionary)

Returns an anchor element (a element) for the specified link text, action, and route values as a route value dictionary.

Parameters

The HTML helper instance that this method extends.

The inner text of the anchor element.

The name of the action.

An object that contains the parameters for a route.

Returns

An anchor element (a element).

Exceptions

The linkText parameter is null or empty.

ActionLink(HtmlHelper, String, String, Object, Object) ActionLink(HtmlHelper, String, String, Object, Object)

Returns an anchor element (a element) for the specified link text, action, route values, and HTML attributes.

Parameters

The HTML helper instance that this method extends.

The inner text of the anchor element.

The name of the action.

An object that contains the parameters for a route. The parameters are retrieved through reflection by examining the properties of the object. The object is typically created by using object initializer syntax.

An object that contains the HTML attributes for the element. The attributes are retrieved through reflection by examining the properties of the object. The object is typically created by using object initializer syntax.

Can anyone tell me how can I submit values to Controller using ActionLink and POST method?
I don’t want to use buttons.
I guess it has something with jquery.

17 Answers 17

You can’t use an ActionLink because that just renders an anchor tag.
You can use a jQuery AJAX post.
Or just call the form’s submit method with or without jQuery (which would be non-AJAX), perhaps in the onclick event of whatever control takes your fancy.

If you’re using ASP MVC3 you could use an Ajax.ActionLink(), that allows you to specify a HTTP Method which you could set to "POST".

You can use jQuery to do a POST for all your buttons. Just give them the same CssClass name.

Use "return false;" at the end of your onclick javascript event if you want to do a server side RedirectToAction after the post otherwise just return the view.

@Aidos had the right answer just wanted to make it clear since it is hidden inside a comment on his post made by @CodingWithSpike.

Here was an answer baked into the default ASP.NET MVC 5 project I believe that accomplishes my styling goals nicely in the UI. Form submit using pure javascript to some containing form.

The fully shown use case is a logout dropdown in the navigation bar of a web app.

ActionLink will never fire post. It always trigger GET request.

Use the following the Call the Action Link:

For submitting the form values use:

It will submit the Data to Customer Controller and CustomerSearchResults Action.

Use this link inside Ajax.BeginForm

My Solution to this issue is a fairly simple one. I have a page that does a customer search one by the whole email and the other by a partial, the partial pulls and displays a list the list has an action link that points to a actionresult called GetByID and passes in the id

the GetByID pulls the data for the selected customer then returns

which is the post method

This has been a difficult problem for me to solve. How can I build a dynamic link in razor and html that can call an action method and pass a value or values to a specific action method? I considered several options including a custom html helper. I just came up with a simple and elegant solution.

The action method

The point here is that Url.Action does not care whether the action method is a GET or a POST. It will access either type of method. You can pass your data to the action method using

the routeValues object. I have tried this and it works. No, you are not technically doing a post or submitting the form but if the routeValues object contains your data, it doesnt matter if its a post or a get. You can use a particular action method signature to select the right method.

I have done the same issue using following code:

This is my solution for the problem. This is controller with 2 action methods

In View I render construct following structure.

Point of interest in Razor View:

JavaScript function confirmDelete(id) which is called when the link generated with @Html.ActionLink is clicked;

confirmDelete() function required id of item being clicked. This item is passed from onClick handler confirmDelete("+feedback.Id+");return false; Pay attention handler returns false to prevent default action — which is get request to target. OnClick event for buttons could be attached with jQuery for all buttons in the list as alternative (probably it will be even better, as it will be less text in the HTML page and data could be passed via data- attribute).

Form has >, in order to find it in confirmDelete() .

Form includes @Html.HttpMethodOverride(HttpVerbs.Delete) in order to use the HttpDelete verb, as action marked with the HttpDeleteAttribute .

In the JS function I do use action confirmation (with help of external plugin, but standard confirm works fine too. Don’t forget to use bind() in call back or var that=this (whatever you prefer).

Form has a hidden element with and name=’id’ . So before the form is submitted after confirmation ( result==true ), the value of the hidden element is set to value passed argument and browser will submit data to controller like this:

Request URL: http://localhost:38874/Feedback/Delete

Request Method:POST Status Code:302 Found

Location:/Feedback Host:localhost:38874 Form Data X-HTTP-Method-Override:DELETE id:5

As you see it is POST request with X-HTTP-Method-Override:DELETE and data in body set to "id:5". Response has 302 code which redirect to Index action, by this you refresh your screen after delete.

ASP.NET — ASP.NET MVC 5 — Генерация маршрутизированных URL

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

Изменение текущего примера

Мы продолжим пользоваться проектом UrlsAndRoutes из предыдущих статей, но внесем в него пару изменений. Во-первых, нужно удалить папку AdditionalControllers вместе с содержащимся в ней файлом HomeController.cs. Чтобы выполнить удаление, щелкните правой кнопкой мыши на папке AdditionalControllers и выберите в контекстном меню пункт Delete.

Во-вторых, необходимо упростить маршруты в приложении. Отредактируйте файл App_Start/RouteConfig.cs согласно примеру:

В проект модульного тестирования понадобится внести два изменения. Первое из них предусматривает удаление метода TestIncomingRoutes(), который в этой статье не применяется, т.к. она посвящена генерации исходящих маршрутов. Чтобы не получить тесты, которые не прошли, просто удалите указанный метод из файла RouteTests.cs.

Второе изменение заключается в добавлении ссылки на пространство имен System.Web.Mvc, для чего в проект модульного тестирования устанавливается NuGet-пакет MVC. Введите в окне консоли NuGet следующую команду:

Пакет MVC 5 необходим для того, чтобы можно было пользоваться вспомогательными методами для генерации исходящих URL. В предыдущих статьях это не требовалось, поскольку поддержка для работы с входящими URL обеспечивается пространствами имен System.Web и System.Web.Routing.

Генерация исходящих URL в представлениях

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

При стандартной конфигурации маршрутизации этот HTML-элемент создает ссылку, которая будет нацелена на метод действия CustomVariable() в контроллере Home. Вручную определяемые URL вроде показанного выше создаются быстро и просто. Однако они также чрезвычайно опасны; изменив схему URL для приложения, вы разрушите все жестко закодированные URL. После этого придется пройтись по всем представлениям в приложении и обновить все ссылки на контроллеры и методы действий — утомительный процесс, чреватый ошибками и сложный в проверке.

Более удачная альтернатива предполагает применение системы маршрутизации для генерации исходящих URL, что обеспечивает использование схемы URL для динамического формирования URL способом, который гарантирует учет схемы URL приложения.

Использование системы маршрутизации для генерирования исходящих URL

Простейший способ генерации исходящего URL в представлении предусматривает вызов вспомогательного метода Html.ActionLink(), как это сделано в примере ниже, в котором показано дополнение, внесенное в представление /Views/Shared/ActionName.cshtml:

Параметрами метода ActionLink() являются текст для ссылки и имя метода действия, на который должна быть нацелена ссылка. Чтобы увидеть результат этого дополнения, запустите приложение и перейдите в браузере на корневой URL:

HTML-разметка, генерируемая методом ActionLink(), основана на текущей конфигурации маршрутизации. Например, используя схему, которая определена в примере выше (и предполагая, что представление визуализировано запросом к контроллеру Home), мы получим следующую HTML-разметку:

Это может выглядеть как слишком длинный путь для воссоздания вручную определенного URL, который был приведен ранее, однако преимущество данного подхода заключается в том, что он обеспечивает автоматическую реакцию на изменения в конфигурации маршрутизации. В демонстрационных целях изменим конфигурацию, добавив в файл RouteConfig.cs новый маршрут, как показано в примере ниже:

Новый маршрут изменяет схему URL для запросов, направляемых контроллеру Home. Запустив приложение, вы увидите, что это изменение отразилось в HTML-разметке, сгенерированной вспомогательным методом HTML по имени ActionLink():

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

Сопоставление исходящих URL с маршрутами

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

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

Ни одно из значений, предоставленных для переменных сегментов, не должно конфликтовать с переменными, имеющими только стандартные значения, которые определены в маршруте. Это переменные, для которых предоставлены стандартные значения, но которые не встречаются в шаблоне URL. Например, в следующем определении маршрута myVar является переменной, имеющей только стандартное значение:

Для соответствия этому маршруту значение для myVar либо не должно предоставляться, либо должно совпадать со стандартным значением.

Значения для всех переменных сегментов должны удовлетворять ограничениям маршрута.

Чтобы было совершенно ясно: система маршрутизации не пытается найти маршрут, который обеспечивает наилучшее совпадение. Она находит только первое совпадение и применяет этот маршрут для генерации URL; любые последующие маршруты игнорируются. По этой причине вначале должны определяться наиболее специфичные маршруты. Генерацию исходящих URL важно протестировать. Попытка генерации URL, для которого не может быть найдено подходящего маршрута, приведет к созданию ссылки с пустым атрибутом href:

Эта ссылка корректно визуализируется в представлении, но не будет функционировать должным образом при щелчке на ней. Если вы генерируете только URL, то результатом будет null, который визуализируется в виде пустой строки в представлениях.

Первый объект Route, удовлетворяющий этому критерию, будет создавать URL, отличный от null, и это завершит процесс генерации URL. Для каждого параметра сегмента будут подставлены выбранные значения параметров, а любая завершающая последовательность стандартных значений будет отброшена. Если переданы явные параметры, которые не соответствуют параметрам сегмента или стандартным параметрам, метод добавит их в виде набора пар "имя/значение" строки запроса.

Направление на другие контроллеры

В стандартной версии метода ActionLink() предполагается, что целью является метод действия в том же самом контроллере, который визуализировал представление. Для создания исходящего URL, который указывает на другой контроллер, можно воспользоваться перегруженной версией метода ActionLink(), позволяющей задать имя контроллера, как показано в примере ниже:

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

После визуализации представления вы увидите, что сгенерирована следующая HTML-разметка:

Запрос к URL, который направляется на метод действия Index() контроллера Admin, был выражен методом ActionLink() в виде /Admin. Система маршрутизации достаточно интеллектуальна и знает, что маршрут, определенный в приложении, по умолчанию будет использовать метод действия Index(), позволяя опускать ненужные сегменты.

Система маршрутизации включает маршруты, которые были определены с использованием атрибута Route, когда выясняет, каким образом нацеливаться на заданный метод действия. В примере ниже демонстрируется изменение имени контроллера в вызове ActionLink(), чтобы он направлялся на действие Index контроллера Customer (в котором ранее мы использовали атрибуты маршрутизации):

В результате генерируется следующая ссылка:

Это соответствует атрибуту Route, который применялся к методу действия Index() контроллера Customer:

Передача дополнительных значений

Значения для переменных сегментов можно передавать с помощью анонимного типа, свойства которого представляют сегменты. В примере ниже приведен пример, который был добавлен в файл представления ActionName.cshtml:

В этом примере мы предоставляем значение для переменной сегмента по имени id. При визуализации представления мы получим следующую HTML-разметку:

Обратите внимание, что предоставленное значение было добавлено как часть строки запроса, чтобы соответствовать шаблону URL маршрута, который описан маршрутом. Причина заключается в отсутствии переменной сегмента, соответствующей id в этом маршруте. В примере ниже мы отредактировали маршруты в файле RouteConfig.cs, оставив только маршрут, имеющий сегмент id:

Запустив приложение еще раз, вы увидите, что вызов вспомогательного метода ActionLink() в представлении ActionName.cshtml генерирует следующий HTML-элемент:

На этот раз значение, присвоенное свойству id, включено в виде сегмента URL, в соответствие с активным маршрутом в конфигурации приложения.

Указание HTML-атрибутов

Мы создали новый анонимный тип, который имеет свойства id и class, и передали его в качестве параметра методу ActionLink() . Для значений дополнительных переменных сегментов передается null, что указывает на отсутствие значений.

Обратите внимание, что свойство class предваряется символом @. Это возможность языка C#, которая позволяет использовать зарезервированные ключевые слова C# в качестве имен для членов класса.

В результате показанного выше вызова ActionLink() получается следующая HTML-разметка:

Генерация полностью определенных URL в ссылках

Все ссылки, сгенерированные до сих пор, содержали относительные URL, но вспомогательный метод ActionLink() можно также использовать для генерации полностью определенных URL, как показано в примере ниже:

Здесь вызывается перегруженная версия метода ActionLink() с максимальным количеством параметров, которая принимает значения для протокола (https в этом примере), имени целевого сервера (google.com), фрагмента URL (fragmentName), а также все другие опции, упомянутые ранее. При визуализации представления метод ActionLink() генерирует следующую HTML-разметку:

Рекомендуется где только возможно использовать относительные URL. Полностью определенные URL создают зависимости от того, каким образом инфраструктура приложения представлена конечным пользователям. Мне приходилось видеть, как работа многих крупных приложений, которые полагались на абсолютные URL, нарушалась из-за несогласованных изменений в сетевой инфраструктуре или политике доменных имен, которые часто находятся за пределами контроля программистов.

Генерация URL (без ссылок)

В примере ниже показаны изменения, внесенные в файл ActionName.cshtml для создания URL с помощью вспомогательного метода Url.Action():

Метод Url.Action() работает аналогично методу Html.ActionLink() за исключением того, что генерирует только URL. Перегруженные версии этого метода и принимаемые ими параметры одинаковы для Url.Action() и Html.ActionLink(), и с помощью Url.Action() можно делать все то же самое, что демонстрировалось для метода Html.ActionLink() в предшествующих разделах. На рисунке ниже показано, как визуализируется URL в примере:

Генерация исходящих URL в методах действий

Главным образом, исходящие URL будет необходимо генерировать в представлениях, но временами требуется делать нечто похожее внутри метода действия. Для этого можно использовать тот же самый вспомогательный метод, что и в представлении; в качестве иллюстрации в примере ниже показан новый метод действия, добавленный к контроллеру Home:

Для маршрутизации в примере приложения переменную myActionUrl можно было бы установить в /Home/Index/MyID, а переменную myRouteUrl — в "/", что согласуется с результатами, генерируемыми вызовом этих вспомогательных методов.

Более общее требование заключается в том, чтобы перенаправить клиентский браузер на другой URL. Это можно сделать, возвратив результат вызова метода RedirectToAction(), как показано в примере ниже:

Результатом выполнения метода RedirectToAction() является экземпляр класса RedirectToRouteResult, который заставляет MVC Framework выдать инструкцию перенаправления на URL, инициирующий указанное действие. Существуют традиционные перегруженные версии метода RedirectToAction(), в которых можно указывать контроллер и значения переменных сегментов в сгенерированном URL.

Чтобы отправить инструкцию перенаправления с использованием URL, сгенерированного только из свойств объекта, можно применить метод RedirectToRoute(). Этот метод также возвращает объект RedirectToRouteResult и обеспечивает в точности тот же самый эффект, как и вызов метода RedirectToAction():

Генерация URL из специфического маршрута

В предыдущих примерах мы предоставили системе маршрутизации возможность выбора маршрута, который будет использоваться для генерации URL или ссылки. В этом разделе мы покажем, как управлять этим процессом и выбирать специфические маршруты. Для демонстрации такой возможности мы изменили конфигурацию маршрутизации в файле RouteConfig.cs:

В конфигурации определены два маршрута, которым назначены имена — MyRoute и MyOtherRoute. Существуют две причины именования маршрутов:

чтобы помнить предназначение маршрута;

чтобы иметь возможность выбрать определенный маршрут для использовании при генерации исходящего URL.

Маршруты организованы так, что наименее специфичные идут в списке первыми. Это означает, что при генерации ссылки с помощью следующего вызова метода ActionLink():

исходящая ссылка всегда будет генерироваться с использованием MyRoute, как показано ниже:

Стандартное поведение сопоставления маршрутов можно переопределить с помощью метода Html.RouteLink(), который позволяет указать, какой маршрут должен применяться:

В результате ссылка, сгенерированная вспомогательным этим методом, выглядит следующим образом:

В данном случае указанный контроллер, Customer, переопределяется маршрутом, поэтому ссылка нацелена вместо него на контроллер Home.

Можно также назначать имена маршрутам, которые определяются с помощью атрибута Route. В примере ниже демонстрируется именование такого маршрута в контроллере Customer:

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

Аргумент против именования маршрутов

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

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