Uma das coisas mais diferentes que mostrei na minha palestra do Web Days foi a possibilidade de utilizar expressões, algo que veio de presente com o LINQ, para criar rotas. Por exemplo, para criar esse html:

<form action="/Categories/Update/1" method="post" >

Utilizei o seguinte código:

<% using (Html.Form((CategoriesController ctl) => ctl.Update(this.ViewData.Model.CategoryID)))
       { %>

Estranho, certo? O que está acontecendo? Se você for olhar para a assinatura do método Form (é um método de extensão):

public static IDisposable Form<T>(this HtmlHelper helper, Expression<Action<T>> postAction) where T : Controller;

Vai notar que o segundo parâmetro sendo passado é uma Expression (uma expressão) de uma Action<T>, onde T deve ser um Controller do MVC (o primeiro parâmetro é um parâmetro do método de extensão, ou seja, é um HtmlHelper). E Action é um delegate, certo? Tá… e aí? Aí que o seguinte código, com lambdas, gera um delegate:

  (CategoriesController ctl) => ctl.Update(this.ViewData.Model.CategoryID)

Só que não é um delegate, o esperado, e sim uma Expression de um delegate. Essa Expression é gerada pelo compilador. Pedi ao Reflector para descompilar o código gerado. Dá uma olhada na viagem:
ParameterExpression CS$0$0000;
base.Html.Form
(
Expression.Lambda<Action>
(
Expression.Call
(
CS$0$0000 = Expression.Parameter(
typeof(CategoriesController), “ctl”),
(MethodInfo) methodof(CategoriesController.Update),
new Expression[] {
Expression.Property
(
Expression.Property
(
Expression.Property
(
Expression.Constant
(
this,
typeof(Edit)),
(MethodInfo) methodof(
ViewPage.get_ViewData,
ViewPage)
),
(MethodInfo) methodof(ViewDataDictionary.get_Model,
ViewDataDictionary)
),
(MethodInfo) methodof(Categories.get_CategoryID)
)
}
),
new ParameterExpression[] { CS$0$0000 }
)
);

Pois é, aquele pequeno delegate virou esse negócio gigantesco, tudo gerado pelo compilador. Como se diz lá fora, isso é “syntatic sugar” da linguagem, querendo dizer que a linguagem permite uma construção super simples e bonita de uma lambda, mas depois ela vira esse negócio todo depois. Já imaginou fazer isso tudo na mão? Não ia valer a pena…

O resultado é uma expressão, ou seja, uma informação sobre a Lambda passada. Quer dizer mais ou menos o que se lê na lambda, ou seja:

Tendo um determinado controlador do tipo CategoriesController, chame o método Update dele com o valor que estiver no campo CategoryID do modelo.

O MVC pega essa informação e transforma em uma tag form, com a chamada no controlador e ação esperados. Inteligente, não é?

E no fim das contas, a função não é nunca chamada, já que não passamos um delegate, mas uma expressão. Para executar a expressão teríamos que compilá-la, o que até é possível (gera um delegate igual ao que lhe deu origem), mas isso não é feito pelo MVC.

O Renato Guimarães já falou do tema expressions no blog dele, e muito bem (tem até vídeo), então não vou ficar repetindo. Dêem uma olhada no blog dele se vocês quiserem aprofundar no assunto. Além desse vídeo que estou linkando tem outros.

Curtiram? Muita loucura? É… a linguagem está evoluindo… temos que evoluir junto. Já imaginaram o C# 4.0? Vai ser cheio de outras loucuras. Eu até agora só ouvi umas histórias beeeeeem complexas. E o Spec# então? Será que vem? Eu apóio.

Giovanni Bassi

Arquiteto e desenvolvedor, agilista, escalador, provocador. É fundador e CSA da Lambda3. Programa porque gosta. Acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é mais eficiente que hierarquia. Foi reconhecido Microsoft MVP há mais de dez anos, dos mais de vinte que atua no mercado. Já palestrou sobre .NET, Rust, microsserviços, JavaScript, TypeScript, Ruby, Node.js, Frontend e Backend, Agile, etc, no Brasil, e no exterior. Liderou grupos de usuários em assuntos como arquitetura de software, Docker, e .NET.