腾讯云开发者社区-腾讯云

开发者社区

文档建议反馈控制台

最新优惠活动

文章/答案/技术大牛

发布

大内老A

专栏作者

840

文章

821815

阅读量

116

订阅数

Dora.Interception，为.NET Core度身打造的AOP框架 [5]：轻松地实现与其他AOP框架的整合

这里所谓的与第三方AOP框架的整合不是说改变Dora.Interception现有的编程，而是恰好相反，即在不改变现有编程模式下采用第三方AOP框架或者自行实现的拦截机制。虽然我们默认提供基于IL Emit实现方式，并且对IL指令进行了深度的优化，但是如果我们真的具有更好的选择，我们可以通过简单的扩展完成对底层拦截机制改变。

2018-12-18

3710

Dora.Interception，为.NET Core度身打造的AOP框架 [4]：与依赖注入框架的无缝集成

Dora.Interception最初的定位就是专门针对.NET Core的AOP框架，所以在整个迭代过程中我大部分是在做减法。对于.NET Core程序开发来说，依赖注入已经成为无处不在并且“深入骨髓”的东西，不论是在进行业务应用的开发，还是进行基础组件的开发，依赖注入是实现“松耦合”最为理想的方式（没有之一）。对于绝大部分AOP框架来说，它们最终都会体现为创建一个能够拦截的“代理对象”来实现对方法调用的拦截，但是.NET Core中针对服务实例的提供完全由通过IServiceProvider接口表示的DI容器来接管，所以Dora.Interception必须将两者无缝地集成在一起。与依赖注入框架的集成不仅仅体现在对可被拦截的代理对象的创建，同样应用在了针对拦截器的定义和注册上。

2018-12-17

3670

Dora.Interception，为.NET Core度身打造的AOP框架 [3]：多样化拦截器应用方式

在《以约定的方式定义拦截器》中，我们通过对拦截器的介绍了Dora.Interception的两种拦截机制，即针对接口的“实例拦截”针对虚方法的“类型拦截”。我们介绍了拦截器的本质以及基于约定的拦截器定义方式，接下来我们将着重关注拦截器的应用问题。

2018-12-14

3710

Dora.Interception，为.NET Core度身打造的AOP框架 [2]：以约定的方式定义拦截器

.net aop 其他 asp.net

上一篇《更加简练的编程体验》提供了最新版本的Dora.Interception代码的AOP编程体验，接下来我们会这AOP框架的编程模式进行详细介绍，本篇文章着重关注的是拦截器的定义。采用“基于约定”的Interceptor定义方式是Dora.Interception区别于其他AOP框架的一个显著特征，要了解拦截器的编程约定，就得先来了解一下Dora.Interception中针对方法调用的拦截是如何实现的。

2018-12-14

3540

TechEmpower最新一轮的性能测试出炉，ASP.NET Core依旧表现不俗

TechEmpower在10月30发布最新一轮（Round 17）针对“Web Framework Benchmarks”的性能测试报告，ASP.NET Core依旧表现不俗，在一些指标上甚至是碾压其他主流Web框架。为此我们做了一个简单的统计，看看ASP.NET Core和其他我们熟悉的Web框架，比如Servlet、Go、NodeJS和PHP之间的差距。

2018-12-05

6710

Dora.Interception, 为.NET Core度身打造的AOP框架：不一样的Interceptor定义方式

相较于社区其他主流的AOP框架，Dora.Interception在Interceptor提供了完全不同的编程方式。我们并没有为Interceptor定义一个接口，正是因为不需要实现一个预定义的接口，Dora.Interception下的Interceptor定义变得更加自由。除此之外，Interceptor的异步执行是我在设计Dora.Interception之初最为关心的问题，也就是说如果Interceptor应用的目标方法是异步的，Interceptor自身也应该被赋予异步执行的能力。接下来我们就来聊聊如果你使用了Dora.Interception，如何定义你的Interceptor。

2018-09-28

3010

依赖注入[2]: 基于IoC的设计模式

正如我们在《控制反转》提到过的，很多人将IoC理解为一种“面向对象的设计模式”，实际上IoC自身不仅与面向对象没有必然的联系，它也算不上是一种设计模式。一般来讲，设计模式提供了一种解决某种具体问题的方案，但是IoC既没有一个针对性的问题领域，其自身没有提供一种可实施的解决方案，所以我更加倾向于将IoC视为一种设计原则。实际上很多我们熟悉的设计模式背后采用了IoC原则，接下来我们就来介绍几种典型的“设计模式”。

2018-08-01

7850

Roslyn还出现这么低级的错误，不应该呀！

前几天对Dora.Interception作了简单的重构，想提供C#脚本来定义Interception Policy，毫无疑问微软提供的编译平台Roslyn使C#脚本化提供了支持。但是没有想到随便尝试了一个简单的功能就出现了问题，我个人觉得这应该是Roslyn的Bug。但是Roslyn经历了这么多次版本的迭代还出现如此低级的错误，实在有点说不过去。

2018-08-01

4320

依赖注入[5]: 创建一个简易版的DI框架[下篇]

为了让读者朋友们能够对.NET Core DI框架的实现原理具有一个深刻而认识，我们采用与之类似的设计构架了一个名为Cat的DI框架。在《依赖注入[4]: 创建一个简易版的DI框架[上篇]》中我们介绍了Cat的基本编程模式，接下来我们就来聊聊Cat的设计和实现。

2018-08-01

5520

ASP.NET Core的路由[2]：路由系统的核心对象——Router

ASP.NET Core应用中的路由机制实现在RouterMiddleware中间件中，它的目的在于通过路由解析为请求找到一个匹配的处理器，同时将请求携带的数据以路由参数的形式解析出来供后续请求处理流程使用。但是具体的路由解析功能其实并没有直接实现在RouterMiddleware中间件中，而是由一个Router对象来完成的。

2018-07-31

1.2K0

ASP.NET Core的路由[1]：注册URL模式与HttpHandler的映射关系

ASP.NET Core的路由是通过一个类型为RouterMiddleware的中间件来实现的。如果我们将最终处理HTTP请求的组件称为HttpHandler，那么RouterMiddleware中间件的意义在于实现请求路径与对应HttpHandler之间的映射关系。对于传递给RouterMiddleware中间件的每一个请求，它会通过分析请求URL的模式并选择并提取对应的HttpHandler来处理该请求。除此之外，请求的URL还会携带相应参数，该中间件在进行路由解析过程中还会根据生成相应的路由参数提供给处理该请求的Handler。为了让读者朋友们对实现在RouterMiddleware的路由功能具有一个大体的认识，我们照例先来演示几个简单的实例。

2018-07-31

1.3K0

如何在ASP.NET Core应用中实现与第三方IoC/DI框架的整合？

我们知道整个ASP.NET Core建立在以ServiceCollection/ServiceProvider为核心的DI框架上，它甚至提供了扩展点使我们可以与第三方DI框架进行整合。对此比较了解的读者朋友应该很清楚，针对第三方DI框架的整合可以通过在定义Startup类型的ConfigureServices方法返回一个ServiceProvider来实现。但是真的有这么简单吗？

2018-07-31

5910

学习ASP.NET Core, 怎能不了解请求处理管道[3]: 自定义一个服务器感受一下管道是如何监听、接收和响应请求的

我们在《服务器在管道中的“龙头”地位》中对ASP.NET Core默认提供的具有跨平台能力的KestrelServer进行了介绍，为了让读者朋友们对管道中的服务器具有更加深刻的认识，接下来我们采用实例演示的形式创建一个自定义的服务器。这个自定义的服务器直接利用HttpListener来完成针对请求的监听、接收和响应，我们将其命名为HttpListenerServer。在正式介绍HttpListenerServer的设计和实现之前，我们先来显示一下如何将它应用到一个具体的Web应用中。我们依然采用最简单的H

2018-03-27

9230

开发自己的Data Access Application Block[下篇]

上接：[原创] 我的ORM: 开发自己的Data Access Application Block - Part I 4. Database 下面来介绍重中之重：Database，绝大部分的Data Access 操作都集中在这个Abstract Database中。这是一个相对庞大的Class，所以不得不采用Partial Class的方式来编写。 Part I：Field 和Property 这些Field 和Property基本上对应我们前面的Configuraiton。此为我们定义了三个Field

2018-02-08

1.3K0

EndpointAddress——不只是一个Uri[下篇]

《上篇》对AddressHeader在服务端和客户端的作用，以及如何通过配置和编成的方式设置AddressHeader进行了详细介绍。现在我们通过一个实例来演示终结点的地址报头如何影响实现终结点选择的消息筛选机制。这个实例通过为服务端终结点指定地址报头实现针对客户端的授权，让经过许可的客户端才能访问这个服务。具体来说，我们将一个代码序列号的GUID作为终结点的地址报头。对于客户端发送的消息，只有具有相应的报头才能访问服务。[三个实例源代码下载地址：实例1、实例2和实例3] 一、无地址报头下服务调用（实例

2018-02-08

5080

EndpointAddress——不只是一个Uri[上篇]

终结点是整个WCF的核心，由经典的ABC三要素组成。作为表示地址的EndpointAddress，很多人仅仅将其看成是一个表示标识服务并且表示服务所在地址的Uri，其实服务标识和定位服务仅仅是EndpointAddress一个基本的功能，它不仅仅是Uri那么简单。一、EndpointAddress的三个功能作为终结点的三要素之一的地址（Address），在基于WCF的通信中不仅仅定位着服务的位置，而且还提供额外的寻址信息。除此之外，终结点地址还和安全有关系，因为它包含着用于进行服务认证的服务身份信息。这

2018-02-08

7890

从Trace和Debug来看条件编译（Conditional Compilation）

条件编译，顾名思义，就是根据在编译时指定的条件决定最后需要编译的代码。条件编译是我们可以针对某些特性的环境编写相应的代码，比如有写的代码只需要在Debug模式下才需要执行，有些代码仅仅是为了在SIT或者UAT环境下有效地进行Troubleshooting，而在Production环境下则不应该执行。通过条件编译机制，我们可以针对某中特定的“条件编译符（Conditional Compilation Symbol）”编写相应的代码。在进行最终编译的时候，通过指定的条件编译符，编译器判断这些特殊的代码是否应该被

2018-02-08

6730

在Entity Framework中使用存储过程（三）：逻辑删除的实现与自增长列值返回

本篇文章通过实例的方式，讨论两个在EF使用存储过程的主题：如何通过实体和存储过程的映射实现逻辑删除；对于具有自增长类型主键的数据表，在进行添加操作的时候如何将正确的值反映在实体对象上。目录一、基于逻辑删除的数据表和存储过程定义二、如何过滤逻辑删除记录三、具有自增长列的存储过程定义四、通过Result Columns Binding将结果集的列于实体属性进行绑定一、基于逻辑删除的数据表和存储过程定义较之物理删除（记录彻底从数据表中清除掉），

2018-02-07

1.7K0

晚绑定场景下对象属性赋值和取值可以不需要PropertyInfo

在《一句代码实现批量数据绑定》中，我通过界面控件ID与作为数据源的实体属性名之间的映射实现了批量数据绑定。由于里面频繁涉及对属性的反射——通过反射从实体对象中获取某个属性值；通过反射为控件的某个属性赋值，所以这不是一种高效的操作方式。为了提升性能，我通过IL Emit的方式创建了一个PropertyAccessor组件，以实现高效的属性操作。如果你看了我在文中给出的三种属性操作性能的测试结果，相信会对PropertyAccessor的作用有深刻的印象。[源代码从这里下载] 目录：一、Prop

2018-02-07

8080

为.NET Core项目定义Item Template

作为这个星球上最强大的IDE，Visual Studio不仅仅提供了很多原生的特性，更重要的是它是一个可定制的IDE，比如自定义Project Template和Item Template就是一个非常

2018-02-07

5760

点击加载更多

社区活动

腾讯技术创作狂欢月

“码”上创作 21 天，分 10000 元奖品池！

Python精品学习库

代码在线跑，知识轻松学

博客搬家 | 分享价值百万资源包

自行/邀约他人一键搬运博客，速成社区影响力并领取好礼

技术创作特训营·精选知识专栏

往期视频·千货材料·成员作品最新动态