visual studio ti aiuta a trovare l'overload giusto di quell'helper (ce ne sono una decina), quando apri la parentesi tonda appare intellisense e basta cliccare sulle frecciette nere che ti fanno scorrere i vari overload. In ogni caso quando devi passare anche il nome del controller la firma da usare è questa:
ActionLink(string testo, string action, string controller, object routevalues, object htmlAttribute);
percio:
codice:
<%: Html.ActionLink(x.ToString(),"Tablatura","Tablatura",new { id = x}, null) %>
per rispondere alla prima domanda, il controller che riceve deve avere in firma un parametro di nome id di tipo string altrimenti quel link ti genera un eccezione una volta cliccato per cui:
codice:
public ActionResult Tablatura(string id)
{
...
}
a parametro query string corrisponde parametro in input del metodo action. La cosa come ti dicevo puo essere piu object oriented se si sfrutta il model binder come ti spegavo su.
In realtà anche cosi il modelbinder entra in azione perche in fondo id è un valore querystring che viene passato e convertito ad un oggetto .net (la stringa in questo caso, ma poteva essere anche un int o un datetime). Se avessi avuto due parametri querystring (id e nome) il model binder sa riconoscerli solo perche PER CONVENZIONE i parametri del action method hanno LO STESSO nome dei parametri quesristring. Se per esempio il parametro di Tablatura invece di chiamarsi "id" lo rinominassi in "key" il gioco non funzionerebbe più. Questo fatto del model binder è solo un aiuto che ti leva la rogna di scrivere codice del tipo:
try
{
id = Convert.ToInt32(Request.QueryString["ID"]);
}
per ogni proprietà
In realtà potresti anche non avvalerti di questo sistema (scelta ovviamente deprecabile). Per farti capire nonostante la route, il link seo friendly ecc. potresti anche fare:
codice:
public ActionResult Tablatura()
{
id = Convert.ToInt32(Request.QueryString["ID"]);
}