Syntax Question: @Html.LabelFor(m => m.UserName)

Question

Going from ASP.NET 2.0 (VB) to MVC 3 (C#), I'm very confused about the syntax being used for the View.

@Html.LabelFor(m => m.UserName)

Where did that m come from? My only guess is that it represents the model that is being passed into the view. I tried changing the m to c and it still works fine.

Is the part of the syntax that involves the "=>" more of a MVC, C#, or Razor element?

Solution 1

Where did that m come from?

It's the parameter in a lambda expression.

My only guess is that it represents the model that is being passed into the view. I tried changing the m to c and it still works fine.

That's because the name doesn't matter. It's just a parameter name, it doesn't actually refer to any existing variable.

Is the part of the syntax that involves the "=>" more of a MVC, C#, or Razor element?

It's C#, but LabelFor uses what the compiler translates m => m.UserName into to extract what it needs to build up the label.

This is a very deep an intricate subject. I suggest that you find a book that you're comfortable with (e.g., C# in Depth is very good on this subject) to understand more. You want to read about lambda expressions and expression trees.

Solution 2

It's a syntax trick that has been present since C# 3.0 (I think; maybe 3.5).

If you were to write this in code (and your Razor view does get translated to a C# code file before compiling, so it really is in code), there are two possible ways the compiler can compile it depending on the context.

If the method LabelFor() expects a delegate, it's compiled to an anonymous method. Alternatively, if the method expects an System.Linq.Expressions.Expression<Func> type, an expression tree is constructed. This is what is happening in your case.

The reason for this convulted syntax is that the expression tree contains enough information, that (combined with Reflection) the LabelFor() method can extract the actual property to which you are referring. If you were to pass it simply as LabelFor(Model.UserName), there wouldn't be enough information for the LabelFor() to do this. It would just get the value from the UserName property. But now it knows where it came from, and can use more Reflection to have a glance at the attributes of the property. Attributes such as DisplayFormat, Required, and others.

The m (or c or whatever) is actually your model. LabelFor is an extension method and it simply passes your model back to your Lambda expression, so that the whole expression tree trick can work. You could also write it like LabelFor(x=>Model.UserName), but I don't think it would work (I haven't tried though, maybe it does).

Solution 3

That's a Lambda Expression, link.

The deal is this: the m is a variable that receives the instance of the model in the given circunstance.
Inside the labelFor, it will call a compile-time created class, which has a method that does what you have passed as an argument to the LabelFor.

A lambda expression can be switched by a delegate, with the exact same results, excepting a minor, really minor performance boost, once.

The general idea is that you are passing a method to be execute somewhere in the LabelFor method.

ex: the method:

public void Dummy(Action<string> action)
{
    if(iFeelLikeIt) {action("I feel Like it");}
}

Should be used as:

Dummy(msg => MessageBox.Show(msg));

Solution 4

This is Lambda Expression. From MSDN:
A lambda expression is an anonymous function that can contain expressions and statements, and can be used to create delegates or expression tree types.

All lambda expressions use the lambda operator =>, which is read as "goes to". The left side of the lambda operator specifies the input parameters (if any) and the right side holds the expression or statement block. The lambda expression x => x * x is read "x goes to x times x."

View more solutions

Comments

[Tocco]

I don't he needs a book for it.

[rkw]

Ah, thanks for the explaining the reason behind the extended syntax.

[Mike Goodwin]

Lambda expressions a syntax trick? They're a really important language feature!

[Vilx-]

Yes. It's a really important syntax trick. :) OK, well, I suppose a lot of language features could be called "syntax tricks". I use the term to mean "something that can be done without using the feature, except it gets a lot more tedious to write". For example, a lambda expression x=>x*2 could be replaced with the more ancient delegate(int x) { return x*2; } syntax. Or, if it is used to construct a Expression<T>, then you could use the explicit Expression methods to build the tree. Of course, the code becomes tedious to the point where it's useless. But it still can be done.

[Vilx-]

@MikeGoodwin - Similarly, a using(x) { ... } is a "syntax trick", because you can replace it with try...finally. The same about foreach and for (because you can replace them with a while), etc.