There must be a reason for everything.
Like filter, it is created to solve a unified code before or after a class of action.
And the helper is to facilitate the development of the view of the production.
Let's solve a few questions to see how the helper evolved.
Up
Topic: How to write a super connection to the home page in view?
The question seems very good to answer:
<a href="/home/index">首页</a>
Bearing
In fact, this can not be called the scheme is the best way to write, did not invoke any method, only pure HTML to solve the problem.
But what if the route rules change? Just like the old
routes.MapRoute(
"Default",
"{controller}/{action}/{id}",
new { controller = "Home", action = "Index", id = "" }
);
Change to
routes.MapRoute(
"Default",
"{controller}/{action}.htm",
new { controller = "Home", action = "Index" }
);
The extension changed, and if you press the last answer, the connection will change to
<a href="/home/index.htm">首页</a>
If there are a lot of references to this route rule in the project, then this batch of changes will certainly be exhausting and error prone.
So what should we do?
So we're going to use Urlhelper.
<a href="<%=Url.Action("Index","Home")% >">首页</a>
这样在Route规则变化的情况下也会得到正确的地址
Turn
The above method allows URLs to respond to changes, but there is another problem is that href= "<%=%>" is difficult to intelligently perceive and debug in VS, so there is a good way to debug it so that the original HtmlHelper
<%=Html.Action("首页","Index","Home")% >
This will facilitate IntelliSense and debugging, and the code is relatively clean
Knot
These humble opinions describe why helpers are present and hope that new learning asp.net MVC's friends will help.