ASP.NET Core中使用表达式树创建URL

当我们在ASP.NET Core中生成一个action的url会这样写:

var url=_urlHelper.Action("Index", "Home");

这样的写法存在的问题在于我们传递了两个字符串类型的参数,而我们又无法避免对action和controller做重命名操作, 例如将index重命名为default, 你无法通过IDE在重命名action的过程中,将

_urlHelper.Action("Index", "Home"); 

重构为

UrlHelper.Action("Default", "Home");

所以我们的目标是:设计出具有静态检查的API,让IDE提示出这个错误来,甚至是重命名时直接把相关代码都能重命名。

目标

设计出类似两组API:

var url = _urlHelper.Action((HomeController c) => c.Index());
//期待输出 /home/index
var link = _urlHelper.Link((ProductController c) => c.Details(10));
//期待输出 http://locahost/product/details/10

设计API

根据上面的需求,定义两组API:

public static string Action<TController>(this IUrlHelper helper,
Expression<Action<TController>> action)
where TController : Controller
{
   //实现
}

public static string Link<TController>(this IUrlHelper helper,
Expression<Action<TController>> action,
string protocal = null, string host = null)
where TController : Controller
{
   //实现
}

实现API

我们实际上最终还是要依赖ASP.NET Core提供的API:

var link = helper.Action(action: actionName, controller:
controllerName, values: routes);

所以问题变成了如何根据(HomeController c) => c.Index()这样的表达式来解析出actionName, ControllerName以及routeValues。

1. 解析ControllerName

解析ControllerName比较简单粗暴,因为我们已经从表达式树中得到了HomeController这个类型,直接取Home字符串即可:

private static string GetControllerName(Type controllerType)
{
    var controllerName = controllerType.Name.EndsWith("Controller")
        ? controllerType.Name.Substring(0,
        controllerType.Name.Length - "Controller".Length)
        : controllerType.Name;
    return controllerName;
}

2. 解析ActionName

由于表达式(HomeController c) => c.Index()是一个MethodCallExpression类型,而Action的名字就是方法名:

private static MethodCallExpression
GetMethodCallExpression<TController>(
Expression<Action<TController>> actionSelector)
{
    var call = actionSelector.Body as MethodCallExpression;
    if (call == null)
    {
        throw new ArgumentException("You must call a method on " +
        typeof(TController).Name, "actionSelector");
    }

    return call;
}

var methodCallExpression = GetMethodCallExpression(action);
var actionName = methodCallExpression.Method.Name;

3. 解析RouteValues

上面两步已经解析出了ControllerName和ActionName,也就是说通过上面的分析已经能完成下面的调用:

var action = helper.Action(action: "index", controller: "home", values: null);
//等价于
var url = _urlHelper.Action((HomeController c) => c.Index());
//输出 /home/index

但是考虑下面的Action:

[HttpGet,Route("product/{id}")]
public IActionResult Details(int id)
{
   //...
}

这个Action期待传入一个int类型的id,也就是说你要通过这样的方式来生成url:

var action = helper.Action(action: "details", controller:
"product", values: new { id = 10 });

所以要想让我们的API正常工作,还需要生成一个object类型:new { id = 10 }。而这个object类型里面的属性正好可以来自于表达式树的方法调用参数:

var action = _urlHelper.Action((ProductController c) => c.Details(10));

要想生成这个匿名对象,需要遍历方法调用表达式的所有参数,分别解析出属性名,例如id; 以及值,例如10。最后再把解析出来的参数字典生成为dynamic类型的对象:
如何解析表达式树请查看expression-trees

public class RouteValueExtractor
{
    public static object GetRouteValues(MethodCallExpression call)
    {
        var routes = new Dictionary<string, object>();

        var parameters = call.Method.GetParameters();
        var pairs = call.Arguments.Select((a, i) => new
        {
            Argument = a,
            ParamName = parameters[i].Name
        });
        foreach (var item in pairs)
        {
            string name = item.ParamName;
            object value = GetValue(item.Argument);
            if (value != null)
            {
                var valueType = value.GetType();
                if (valueType.IsValueType)
                {
                    routes.Add(name, value);
                }
                else
                {
                    throw new NotSupportedException("Unsupported parameter type {0}");
                }

            }
        }

        return DictionaryToObject(routes);
    }

    private static object GetValue(Expression expression)
    {
        if (expression.NodeType == ExpressionType.Constant)
        {
            return ((ConstantExpression) expression).Value;
        }

        throw new NotSupportedException("Unsupported parameter expression");
    }

    private static dynamic DictionaryToObject(IDictionary<string, object> dictionary)
    {
        var expandoObj = new ExpandoObject();
        var expandoObjCollection = (ICollection<KeyValuePair<string, object>>) expandoObj;

        foreach (var keyValuePair in dictionary)
        {
            expandoObjCollection.Add(keyValuePair);
        }

        dynamic eoDynamic = expandoObj;
        return eoDynamic;
    }
}

一个完整的API实现:

public static string Action<TController>(this IUrlHelper helper,
Expression<Action<TController>> action)
where TController : Controller
{
    var controllerName = GetControllerName(typeof(TController));
    var methodCallExpression = GetMethodCallExpression(action);
    var actionName = methodCallExpression.Method.Name;

    var routes = RouteValueExtractor.GetRouteValues(methodCallExpression);

    var link = helper.Action(action: actionName, controller:
    controllerName, values: routes);

    return link;
}

原文地址:https://www.cnblogs.com/xiandnc/p/9746274.html

时间: 2024-10-18 21:27:06

ASP.NET Core中使用表达式树创建URL的相关文章

ASP.NET Core中的依赖注入(5): ServiceProvider实现揭秘 【总体设计 】

本系列前面的文章我们主要以编程的角度对ASP.NET Core的依赖注入系统进行了详细的介绍,如果读者朋友们对这些内容具有深刻的理解,我相信你们已经可以正确是使用这些与依赖注入相关的API了.如果你还对这个依赖注入系统底层的实现原理具有好奇心,可以继续阅读这一节的内容. 目录一.ServiceCallSite 二.Service 三.ServiceEntry 四.ServiceTable 五.ServiceProvider 作为DI容器的体现,ServiceProvider是ASP.NET Co

ASP.NET Core中使用GraphQL - 第五章 字段, 参数, 变量

ASP.NET Core中使用GraphQL ASP.NET Core中使用GraphQL - 第一章 Hello World ASP.NET Core中使用GraphQL - 第二章 中间件 ASP.NET Core中使用GraphQL - 第三章 依赖注入 ASP.NET Core中使用GraphQL - 第四章 GrahpiQL 字段# 我们已经很好的理解了GraphQL中的字段.在之前HelloWorldQuery的例子中,我们添加了2个字段hello和howdy. 它们都是标量字段.正

Asp.net core中的websocket

Websocket是html5后的产物,对于asp.net core中也得到了支持,首先在NuGet中添加Microsoft.AspNetCore.WebSockets的引用(现在是1.0.1版本,2017年3月7日发布的). 首先在Configure中添加中间件 //添加websocket中间件 app.UseWebSockets(); 接下来就要定义自己处理websocket的中间件了,代码如下: using Microsoft.AspNetCore.Http; using System;

ASP.NET Core中的依赖注入(5): ServiceProvider实现揭秘 【解读ServiceCallSite 】

通过上一篇的介绍我们应该对实现在ServiceProvider的总体设计有了一个大致的了解,但是我们刻意回避一个重要的话题,即服务实例最终究竟是采用何种方式提供出来的.ServiceProvider最终采用何种方式提供我们所需的服务实例取决于最终选择了怎样的ServiceCallSite,而服务注册是采用的ServiceDescriptor有决定了ServiceCallSite类型的选择.我们将众多不同类型的ServiceCallSite大体分成两组,一组用来创建最终的服务实例,另一类则与生命周

如何在ASP.NET Core中应用Entity Framework

注:本文提到的代码示例下载地址> How to using Entity Framework DB first in ASP.NET Core 如何在ASP.NET Core中应用Entity Framework 首先为大家提醒一点,.NET Core和经典.NET Framework的Library是不通用的,包括Entity Framework! 哪怎么办? 别急,微软为.NET Core发布了.NET Core版本的Entity Framework,具体配置方法与经典.NET Framew

如何在ASP.NET Core中实现一个基础的身份认证

注:本文提到的代码示例下载地址> How to achieve a basic authorization in ASP.NET Core 如何在ASP.NET Core中实现一个基础的身份认证 ASP.NET终于可以跨平台了,但是不是我们常用的ASP.NET, 而是叫一个ASP.NET Core的新平台,他可以跨Windows, Linux, OS X等平台来部署你的web应用程序,你可以理解为,这个框架就是ASP.NET的下一个版本,相对于传统ASP.NET程序,它还是有一些不同的地方的,比

ASP.NET Core中使用xUnit进行单元测试

单元测试的功能自从MVC的第一个版本诞生的时候,就是作为一个重要的卖点来介绍的,通常在拿MVC与webform比较的时候,单元测试就是必杀底牌,把webform碾压得一无是处. 单元测试的重要性不用多说了,有单元测试的做兜底的项目,好比给开发人员买了份保险,当然这个保险的质量取决于单元测试的质量,那些一路Mock的单元测试,看起来很美,但是什么都cover不到.目前工作中的一个老项目,有2万多个单元测试用例,其中不少是用心之作,真正落实到了业务逻辑,开发人员可以放心的去修改代码,当然一切都必须按

ASP.NET Core中的依赖注入(2):依赖注入(DI)

参考页面: http://www.yuanjiaocheng.net/ASPNET-CORE/project-layout.html http://www.yuanjiaocheng.net/ASPNET-CORE/projectjson.html http://www.yuanjiaocheng.net/ASPNET-CORE/core-configuration.html http://www.yuanjiaocheng.net/ASPNET-CORE/core-middleware.htm

ASP.NET Core中的依赖注入(5):ServicePrvider实现揭秘【补充漏掉的细节】

到目前为止,我们定义的ServiceProvider已经实现了基本的服务提供和回收功能,但是依然漏掉了一些必需的细节特性.这些特性包括如何针对IServiceProvider接口提供一个ServiceProvider对象,何创建ServiceScope,以及如何提供一个服务实例的集合. 一.提供一个ServiceProvider对象 我们知道当将服务类型指定为IServiceProvider接口并调用ServiceProvider的GetService方法是,ServiceProvider对象本