如果希望 HTML 元素显示值，可以编写代码来更改显示内容。如果值发生更改，则需要编写额外的代码以更新显示内容。
在第一篇文章中，有提到过组件（Component）这个概念。组件在 Blazor 中是必不可少的，UI 全靠它组装起来，和前端的 JS 组件是一个意思，比如：vue component、react component 等等。借用官方文档的描述：
本文主要讨论Blazor事件内容，由于blazor事件部分很多，所以会分成上下两篇，本文为第二篇。
上一次我们学习了Blazor组件相关的知识（Asp.net Core Blazor Webassembly - 组件）。这次继续学习Blazor的数据绑定相关的知识。当代前端框架都离不开数据绑定技术。数据绑定技术以数据为主导来驱动UI界面，用户对数据的修改会实时提现在UI上，极大的提高了开发效率，让开发者从繁琐的dom操作中解脱出来。对于数据绑定.NET开发者并不会陌生，WPF里大量应用数据绑定技术，有过WPF开发经验的同学其实很容易理解前端的数据绑定。总之数据绑定技术及其概念、思维极其重要。下面让我们看看Blazor的数据绑定技术。
目前的4篇日志是来自我们写好的假数据，但正常来说不会这样做，而是有个按钮让用户点击了之后，增加或减少日志的数量。
本文主要讨论Blazor事件内容，由于blazor事件部分很多，所以会分成上下两篇，本文为第一篇，后续会有第二篇。
在 ASP.NET Razor 中，我们可以创建自定义的组件（通常称为“Razor 组件”或“Blazor 组件”），并为这些组件定义事件。这些事件允许组件的用户在特定情况发生时执行代码，例如用户点击按钮、组件的状态发生变化等。同时，HTML 元素也有内置的事件，如 onclick、onchange 等，这些事件允许我们在浏览器端直接响应用户的交互。
现在前端几大轮子全面组件化。组件让我们可以对常用的功能进行封装，以便复用。组件这东西对于搞.NET的同学其实并不陌生，以前ASP.NET WebForm的用户控件其实也是一种组件。它封装html代码，封装业务逻辑，对外提供属性事件等信息，它完完全全就是个组件，只是用户控件跑在服务端，而现在的组件大多数直接跑在前端。现在Blazor Webassembly微软正式把组件带到前端，让我们看看它是怎么玩的。
上一篇写数据绑定的文章，写到最后留了一个坑。当子组件绑定父组件的一个字段，并且子组件修改它的时候父组件不能实时进行同步更新UI的问题，最近终于在Blazui作者的指导下搞定了。
.NET Core 3.0 Preview 3已经推出，它包含了一系列关于ASP.NET Core的新的更新。
参考: http://resnikb.wordpress.com/2009/05/18/passing-ccli-delegate-to-native-code/ C++/CLI可以直接执行C++,
上周在公司做了一个关于.NET Core依赖注入的培训，有人提到一个问题：如果同一个服务接口，需要注册多个服务实现类型，在消费该服务会根据当前上下文动态对选择对应的实现。这个问题我会被经常问到，我们不妨使用一个简单的例子来描述一下这个问题。假设我们需要采用ASP.NET Core MVC开发一个供前端应用消费的微服务，其中某个功能比较特殊，它需要针对消费者应用类型而采用不同的处理逻辑。我们将这个功能抽象成接口IFoobar，具体的功能实现在InvokeAsync方法中。
从TcpServer开始，找到了EventLoop，在EventLoop中又找到了两个重要组成部分，Chanel和Poller，那就自底向上。
最近Blazor热度很高，传说马上就要发布正式版了，做为微软脑残粉，赶紧也来凑个热闹，学习一下。
发布于 2017-09-25 18:02 更新于 2017-10-19 13:13
在APP中，我们经常会需要一个广播机制，用以跨页面事件通知，比如一个需要登录的APP中，页面会关注用户登录或注销事件，来进行一些状态更新。
1. 在build.gradle（app）文件的dependencies中添加对以下项的依赖：
ASP.NET Core的请求处理管道由一个服务器和一组中间件组成，位于 “龙头” 的服务器负责请求的监听、接收、分发和最终的响应，针对请求的处理由后续的中间件来完成。中间件最终体现为一个Func<RequestDelegate, RequestDelegate>委托，但是我们具有不同的定义和注册方式。(本篇提供的实例已经汇总到《ASP.NET Core 6框架揭秘-实例演示版》）
构成HostBuilderContext上下文的两个核心对象（表示配置的IConfiguration对象和表示承载环境的IHostEnvironment对象）可以直接注入Startup构造函数中进行消费。由于ASP.NET Core应用中的承载环境通过IWebHostEnvironment接口表示，IWebHostEnvironment接口派生于IHostEnvironment接口，所以也可以通过注入IWebHostEnvironment对象的方式得到当前承载环境相关的信息。
上周初步对Blazor WebAssembly进行了初步的探索(ASP.NET Core Blazor 初探之 Blazor WebAssembly)。这次来看看Blazor Server该怎么玩。
Dora.Interception 1.0（Github地址：可以访问GitHub地址：https://github.com/jiangjinnan/Dora）推出有一段时间了，最近花了点时间将它升级到2.0，主要有如下的改进： 提供了原生的动态代理生成底层框架Dora.DynamicProxy：之前依赖第三方框架Castle实现最底层的代理生成，但是它不支持基于Task的并行编程（也就是说通过它编写的Interceptor无法实现异步执行），所以我采用IL Emit的方式自行实现了这部分的功能，这些底层的
Dora.Interception（github地址，觉得不错不妨给一颗星）有别于其他AOP框架的最大的一个特点就是采用针对“约定”的拦截器定义方式。如果我们为拦截器定义了一个接口或者基类，那么拦截方法将失去任意注册依赖服务的灵活性。除此之外，由于我们采用了动态代码生成的机制，我们可以针对每一个目标方法生成对应的方法调用上下文，所以定义在拦截上下文上针对参数和返回值的提取和设置都是泛型方法，这样可以避免无谓的装箱和拆箱操作，进而将引入拦截带来的性能影响降到最低。
对于所有的AOP框架来说，多个拦截器最终会应用到某个方法上。这些拦截器按照指定的顺序构成一个管道，管道的另一端就是针对目标方法的调用。从设计角度来将，拦截器和中间件本质是一样的，那么我们可以按照类似的模式来设计拦截器。
相较于社区其他主流的AOP框架，Dora.Interception在Interceptor提供了完全不同的编程方式。我们并没有为Interceptor定义一个接口，正是因为不需要实现一个预定义的接口，Dora.Interception下的Interceptor定义变得更加自由。除此之外，Interceptor的异步执行是我在设计Dora.Interception之初最为关心的问题，也就是说如果Interceptor应用的目标方法是异步的，Interceptor自身也应该被赋予异步执行的能力。接下来我们就来聊
相较于社区其他主流的AOP框架，Dora.Interception在Interceptor提供了完全不同的编程方式。我们并没有为Interceptor定义一个接口，正是因为不需要实现一个预定义的接口，Dora.Interception下的Interceptor定义变得更加自由。除此之外，Interceptor的异步执行是我在设计Dora.Interception之初最为关心的问题，也就是说如果Interceptor应用的目标方法是异步的，Interceptor自身也应该被赋予异步执行的能力。接下来我们就来聊聊如果你使用了Dora.Interception，如何定义你的Interceptor。
发布于 2017-10-14 09:18 更新于 2018-02-19 22:31
基于IHostBuilder/IHost的服务承载系统建立在依赖注入框架之上，它在服务承载过程中依赖的服务（包括作为宿主的IHost对象）都由代表依赖注入容器的IServiceProvider对象提供。在定义承载服务时，也可以采用依赖注入方式来消费它所依赖的服务。作为依赖注入容器的IServiceProvider对象能否提供我们需要的服务实例，取决于相应的服务注册是否预先添加到依赖注入框架中。服务注册可以通过调用IHostBuilder接口或者IWebHostBuilder接口相应的方法来完成，前者在《服务承载系统》已经有详细介绍，下面介绍基于IWebHostBuilder接口的服务注册。[本文节选自《ASP.NET Core 3框架揭秘》第11章, 更多关于ASP.NET Core的文章请点这里]
ASP.NET Core应用默认的请求处理管道是由注册的IServer对象和HostingApplication对象组成的，后者利用一个在创建时提供的RequestDelegate对象来处理IServer对象分发给它的请求。而RequestDelegate对象实际上是由所有的中间件按照注册顺序创建的。换句话说，这个RequestDelegate对象是对中间件委托链的体现。如果将RequestDelegate替换成原始的中间件，那么ASP.NET Core应用的请求处理管道体现为下图所示的形式。[本文节选自《ASP.NET Core 3框架揭秘》第13章, 更多关于ASP.NET Core的文章请点这里]
本系列前面的五篇文章主要介绍Dora.Interception（github地址，觉得不错不妨给一颗星）的编程模式以及对它的扩展定制，现在我们来聊聊它的设计和实现原理。
ASP.NET Core可以视为一种底层框架，它为我们构建出了基于管道的请求处理模型，这个管道由一个服务器和多个中间件构成，而与路由相关的EndpointRoutingMiddleware和EndpointMiddleware是两个最为重要的中间件。MVC和gRPC开发框架就建立在路由基础上。本篇提供了四个实例用来演示如何利用路由、MVC和gRPC来开发API/APP。(本篇提供的实例已经汇总到《ASP.NET Core 6框架揭秘-实例演示版》）
IoC主要体现了这样一种设计思想：通过将一组通用流程的控制权从应用转移到框架中以实现对流程的复用，并按照“好莱坞法则”实现应用程序的代码与框架之间的交互。我们可以采用若干设计模式以不同的方式实现IoC，比如我们在《依赖注入[2]: 基于IoC的设计模式》介绍的模板方法、工厂方法和抽象工厂，接下来我们介绍一种更为有价值的IoC模式，即依赖注入（DI：Dependency Injection，以下简称DI）。
ASP.NET Core具有一个以ServiceCollection和ServiceProvider为核心的依赖注入框架，虽然这只是一个很轻量级的框架，但是在大部分情况下能够满足我们的需要。不过我觉得它最缺乏的是针对AOP的支持，虽然这个依赖注入框架提供了扩展点使我们可以很容易地实现与第三方框架的集成，但是我又不想“节外生枝”，为此我们趁这个周末写了一个简单的Interception框架来解决这个问题。通过这个命名为Dora.Interception的框架，我们可以采用一种非常简单、直接而优雅地（呵呵）在这
System.Runtime.CompilerServices命名空间下有4个以“Caller”为前缀命名的Attribute，我们可以将它标注到方法参数上自动获取当前调用上下文的信息，比如当前的方法名、某个参数的表达式、当前源文件的路径，以及当前代码在源文件中的行号。
IoC主要体现了这样一种设计思想：通过将一组通用流程的控制权从应用转移到框架之中以实现对流程的复用，并按照“好莱坞法则”实现应用程序的代码与框架之间的交互。我们可以采用若干设计模式以不同的方式实现IoC，比如我们在前面介绍的模板方法、工厂方法和抽象工厂，接下来我们介绍一种更有价值的IoC模式：依赖注入（DI：Dependency Injection）。
系统服务是Android中非常重要的一部分, 像ActivityManagerService, PackageManagerService, WindowManagerService, 这些系统服务都是Framework层的关键服务, 本篇文章主要讲一下如何基于Android源码添加一个系统服务的完整流程, 除了添加基本系统服务, 其中还包含添加JNI部分代码和App通过AIDL调用的演示Demo, 调用包含App调用服务端, 也包含服务端回调App, 也就是完成一个简单的双向通信.
在 WPF 程序中，可能会存在 Application.Current.Dispatcher.Xxx 这样的代码让一部分逻辑回到主 UI 线程。因为发现在调用这句代码的时候出现了 NullReferenceException，于是就有三位小伙伴告诉我说 Current 和 Dispatcher 属性都可能为 null。
InheritedWidget 是 Flutter 中非常重要的一个功能型 Widget，它可以高效的将数据在Widget 树中向下传递、共享，这在一些需要在 Widget 树中共享数据的场景中非常方便，如 Flutter 中，正是通过 InheritedWidget 来共享应用主题( Theme )和 Locale (当前语言环境)信息的。
在本文中，我们将介绍如何使用 .NET Core 中的中间件来自定义规范响应，以便在 API 调用时返回统一的格式和错误信息。中间件是一种可以在请求和响应管道中执行逻辑的软件组件，它可以对请求或响应进行修改、拦截或处理。我们将使用一个简单的示例来演示如何创建和使用自定义规范响应的中间件。
很久之前开发了一个名为Dora.Interception的开源AOP框架（github地址：https://github.com/jiangjinnan/Dora，如果你觉得这个这框架还有那么一点价值，请不吝多点一颗星）,最近对它作了一些改进（包括编程模式和性能，目前版本升级到2.1.2）。一直以来我对软件设计秉承的一个理念就是：好的设计应该是简单的设计。和其他AOP框架相比，虽然Dora.Interception提供的编程模式已经显得足够简单，但是我觉得还应该再简单点，再简单点。这个新版本对拦截器的定义和应用提供了更加简单的定义方式，同时对扩展性方法作了较大的改进，接下来我们通过一个简单实例来体验一下。源代码从这里下载。
.NET Core正式发布之后，我为.NET Core度身定制的AOP框架Dora.Interception也升级到3.0。这个版本除了升级底层类库（.NET Standard 2.1）之外，我还对它进行大范围的重构甚至重新设计。这次重构大部分是在做减法，其目的在于使设计和使用更加简单和灵活，接下来我们就来体验一下在一个ASP.NET Core应用程序下如何使用Dora.Interception。
现在每次启动项目，预设路径都会是/，但我们目前没有Component套用这个路由，要自己切换到Post实在有些麻烦，另外Menu的图案也跟名称不符，我们来调整一下。
在 .NET Framework 时，我们可以通过V8.NET等组件来运行 JavaScript，不过目前我看了好几个开源组件包括V8.NET都还不支持 .NET Core ，我们如何在 .NET Core 中运行 JavaScript 呢，答案是使用 NodeServices。关于为何有在 .NET Core 中执行 JavaScript 这种需求，比较特殊，举个栗子：当你做模拟登录时，目标网站可能采用一些加密算法来计算特殊的值，如果你要完全模拟，那么除了用C#翻译这个算法还有个办法就是直接将这段加密算法JS代码拷贝使用C#来执行。还举个栗子：SPA服务端渲染，比如Angular、 React等。
中间件(Middleware)是ASP.NET Core中的一个重要特性。**所谓中间件就是嵌入到应用管道中用于处理请求和响应的一段代码**。ASP.NET Core Middleware可以分为两种类型：
一般认为 WPF 的 Dispatcher 的 InvokeAsync 方法是 BeginInvoke 方法的平替方法和升级版，接近在任何情况下都应该在业务层使用 InvokeAsync 方法代替 BeginInvoke 方法。然而在异常的处理上，这两个方法还是有细微的差别的，不能说是坏事，依然可以认为使用 InvokeAsync 方法代替 BeginInvoke 方法是正确的。本文将记录这两个在抛出异常时，进入的统一异常处理事件的差别
上一篇《更加简练的编程体验》提供了最新版本的Dora.Interception代码的AOP编程体验，接下来我们会这AOP框架的编程模式进行详细介绍，本篇文章着重关注的是拦截器的定义。采用“基于约定”的Interceptor定义方式是Dora.Interception区别于其他AOP框架的一个显著特征，要了解拦截器的编程约定，就得先来了解一下Dora.Interception中针对方法调用的拦截是如何实现的。
介绍 Nim语言不限制开发人员使用哪种具体的编码风格， 但为了社区的发展，在编写一些标准库的时候还是应该遵从统一的编码风格 这篇文章会列出一系列的编码风格准则，供大家参考。 但值得注意的是，有很多例外场景会与这些准则相悖， 而且，nim语言非常灵活，在一些特定上下文中，这些编码风格准则也不适用。 跟python相似，python的编码风格在不断演化、改变， nim语言也是这样，随着时间的推移，这个编码风格准则也会改变。 在编写nim的基础类库、编译器、官方工具的时候， 强制要求遵从这些编码风格准则 间距和空
本文记录一个 WPF 已知问题，在 ObservableCollection 的 CollectionChanged 事件里面，绕过 ObservableCollection 的异常判断逻辑，强行修改集合内容，修改之后的 UI 层将不能符合预期。本文将告诉大家此问题的复现方法和修复方法
中间件(Middleware)是ASP.NET Core中的一个重要特性。所谓中间件就是嵌入到应用管道中用于处理请求和响应的一段代码。ASP.NET Core Middleware可以分为两种类型：
部分视图是普通的视图文件(.cshtml)，可以嵌入到另外的视图文件里，这意味这相同的视图文件能被使用在多个地方并且减少代码重复，如果在我们应用程序中有重复的视图，我们可以将这个视图作为部分视图，在别的视图中加载这个文件，这种方式可以阻止代码重复
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
