EventBus

参考博客： https://blog.csdn.net/harvic880925/article/details/40660137 EventBus简介 EventBus有哪些优点 Demo案例分享及问题解决 一、什么是EventBus 由greenboot组织贡献(该组织还贡献了greenDAO),一个Android事件发布/订阅轻量级框架。 EventBus可以代替Android传统的Intent,Handler,Broadcast或接口函数,在Fragment,Activity,Service线程之间传递数据，执行方法。 EventBus有五种线程模式分别是： POSTING :默认，表示事件处理函数的线程和发布事件的线程在同一个线程。 MAIN :表示事件处理函数的线程在UI主线程（不能进行耗时操作） BACKGROUND :表示事件处理函数的线程在后台线程，因此不能进行UI操作，如果发布事件的线程是UI主线程那么时间处理函数将会开启一个后台线程，如果发布事件的函数在后台线程，那么事件处理函数就使用该线程。 ASYNC :表示无论时间发布的线程是哪一个，事件处理函数始终会新建一个子线程运行（不能进行UI操作） MAIN_ORDERED :EventBus3.1.1之后新加入的，和MAIN不同的是一定会排队执行 二、EventBus有哪些优点？ 简化了组件间的通讯。

背景 相信前面几篇关于微服务的文章也介绍了那么多了，在构建微服务的过程中确实需要这么一个东西，即便不是在构建微服务，那么在构建分布式应用的过程中也会遇到分布式事务的问题，那么 CAP 就是在这样的背景下诞生的。 最初打算做这个东西是在去年（2016）年底，最初是为了解决分布式系统中的分布式事务的问题，然后当时有了一个大概的概念轮廓，当时我对于前面两篇文章中关于异步消息和微服务之间通讯还不是太了解，只是觉得这样能够解决这一系列的问题，然后就着手做了，最后发现和这些概念竟然不谋而合。 经过大半年的不断重构以及修改，最终 CAP 1.0 版本发布了。作为一个开源项目，最初项目是在我的个人Github下，然后于上个月已经贡献给了 .NET China Foundation 组织，目前该项目由我和 DotNetCore 项目组共同维护。 CAP 介绍 Github： https://github.com/dotnetcore/CAP 开源协议：MIT CAP 是一个在分布式系统中（SOA，MicroService）实现事件总线及最终一致性（分布式事务）的一个开源的 C# 库，她具有轻量级，高性能，易使用等特点。 你可以轻松的在基于 .NET Core 技术的分布式系统中引入CAP，包括但限于 ASP.NET Core 和 ASP.NET Core on .NET Framework。 CAP

背景 相信前面几篇关于微服务的文章也介绍了那么多了，在构建微服务的过程中确实需要这么一个东西，即便不是在构建微服务，那么在构建分布式应用的过程中也会遇到分布式事务的问题，那么 CAP 就是在这样的背景下诞生的。 最初打算做这个东西是在去年（2016）年底，最初是为了解决分布式系统中的分布式事务的问题，然后当时有了一个大概的概念轮廓，当时我对于前面两篇文章中关于异步消息和微服务之间通讯还不是太了解，只是觉得这样能够解决这一系列的问题，然后就着手做了，最后发现和这些概念竟然不谋而合。 经过大半年的不断重构以及修改，最终 CAP 1.0 版本发布了。作为一个开源项目，最初项目是在我的个人Github下，然后于上个月已经贡献给了 .NET China Foundation 组织，目前该项目由我和 DotNetCore 项目组共同维护。 CAP 介绍 Github： https://github.com/dotnetcore/CAP 开源协议：MIT CAP 是一个在分布式系统中（SOA，MicroService）实现事件总线及最终一致性（分布式事务）的一个开源的 C# 库，她具有轻量级，高性能，易使用等特点。 你可以轻松的在基于 .NET Core 技术的分布式系统中引入CAP，包括但限于 ASP.NET Core 和 ASP.NET Core on .NET Framework。 CAP

MVC 是什么 MVC (Model-View-Controller) 是一种软件设计模式.它强调分离软件的业务逻辑和显示. 这种“分离”提供了更好的分工和改进的维护 一些其他的模式也是基于MVC来设计的, 像 MVVM (Model-View-Viewmodel), MTP (Model-View-Presenter), 和 MVW (Model-View-Whatever) 简单来说MVC是一种设计模式，在前后端都用到了这种设计模式 M - Model : 模型持有所有的数据、状态和程序逻辑 V - View : 负责界面的布局和显示 C - Controller : 负责模型和界面之间的交互 用伪代码来解释一下 1. M: const m = { data : x // 里面是一些需要更新和改变的数据 } 2. V const v = { el : el , // el 相当于一个容器，来放置动态渲染的 html html : `<div>我是需要渲染的{{x}}</div>` , //把 m 里的数据 render ( v . el ){ // 这里让 m.data.x 替换成 html 的 {{x} } 然后加到 v . el 中 } 3. C const c = { events : { "click #add" : "add" , "click #reduce" :

众所周知，在 vue中，如果想定义一个全局变量的方法很简单，直接在 vue的原型上挂载属性或者方法即可。 但是，加上了typescript之后, Vue.prototype.$xxx = xxx 这种挂载方式就不行了。无论在哪里都访问不了挂载的内容。Vue原型上也没有。那怎么办呢？ 第一种方式（推荐）：插件 官方文档在 TypeScript 支持 这一项中的 增强类型以配合插件使用 表示了可以用 插件的方式 来定义全局变量，然后用 xxx.d.ts 这种文件来声明类型。 那就开始开发插件： 官方开发插件说明 插件最重要的就是 install 方法。举个最简单的例子： testInstall.ts const protoInstall = { install: (Vue:any,options:any) => { Vue.prototype.$install = function (){ console.log( 'install' ) }; Vue.prototype.$testData = 'testData' ; } } export default protoInstall; （1）不要说我Vue:any,options:any 这种写法，因为我不知道这两个的类型到底是什么ヾ(。￣□￣)ﾂ゜゜゜ main.ts import hhInstall from './assets

背景 公司业务中有个场景，需要在用户点击标签的时候，把标签内容进行处理成类似微博话题的形式，插入到 textarea 中。 textarea 和标签是页面的两个组件，正常情况我可以点击标签后向外抛出事件，页面去监听，然后再把数据传给 textarea ，但这样的处理麻烦，所以就想仿照 Vue 的 EventBus 来实现小程序的兄弟组件传值。 首先先看下demo： 标签的部分和输入框部分是页面的两个组件，我们要做的就是点击标签的时候，将标签的内容添加到输入框中。 实现思路 实现方式一：点击标签的时候，拿到标签的文本内容，然后调用微信的 triggerEvent API 向外抛出一个事件；然后在页面中监听这个事件，拿到标签组件抛出的标签文本后，将其设置进页面的 data 中，然后将其传给 输入框组件，输入框组件通过 observers 监听传入的文本数据，最后将其拼好，赋值给输入框的的 value。 方式一是很容易想到的方案，但是缺点很明显，实现的过程太过于繁琐了，所以方式一直接 pass，我们重点来研究另一个实现方案——EventBus。 实现方式二：方式二我们就仿照 Vue 的 EventBus 来实现兄弟组件传值，实质其实利用发布订阅模式。 首先是当我们点击标签的时候，我们需要向外触发一个事件，然后把标签的内容携带过去，它就是消息的发布者；然后我们需要在 textarea

Reface.AppStarter 中的事件总线功能是通过 Reface.EventBus 提供的。 参考文章 : Reface.AppStarter 框架初探 使用 Reface.EventBus ，你可以在 Reface.AppStarter 框架外使用事件总线的功能。 Reface.EventBus 提供了两个版本的包 Reface.EventBus 、 Reface.Core.EventBus ，分别工作在 .Net Framework 和 .Net Core 平台上。 除了一些细节的不同，这两个版本的使用方法完全相同。 基本篇 下面我们一起来了解如何使用 Reface.EventBus 来 定义事件 、 定义监听器 、 注册监听器 、 发布事件 。 定义事件 事件是一个单独类型，它继承于 Reface.EventBus.Event 或 其子类 , 我们先看看 Event 的定义 public class Event { public object Source { get; private set; } public Dictionary<string, object> Context { get; private set; } public Event(object source) { if (source == null) throw new

下面进入正文，本文会列举一些平时面试时问到的问题和答案，并说明我在当时问到这个问题时所期望对方的回答： vue生命周期（钩子函数） 问题 请说一下vue的生命周期函数（钩子函数）。 问题描述 首先关于生命周期函数，一般我的第一个问题就是这个，我认为是每个使用vue的都要清楚的，如果这个问题答的问题很大其实我都不太想继续往下进行了。 即使英语不标准（我就是不标准的人，并不是说这是个问题）也要去把关键点说清楚，哪个地方有ed哪个地方没有ed其实是很关键的，或者可以手写下来，因为常用的就是created和mounted所以前4个可以清楚的手写出来并不难，后面4个不去详细说明都没事。（我自己工作中基本没用过后面4个） 在哪个周期能够首次拿到data数据和在哪个周期能够首次拿到mounted中的dom元素，如果没有说到这个问题，我一般会一直往下问，直到他说出来这两个答案。 期望答案 beforeCreate、created（此时需说明可以在created中首次拿到data中定义的数据）、beforeMount、mounted（此时需说明dom树渲染结束，可访问dom结构）、 beforeUpdate、updated、beforeDestroy、destroyed computed中的getter和setter 问题 说一下computed中的getter和setter。 问题描述 很多情况

目 录（本篇字数：1610） 介绍 实现步骤 一、设置style主题 二、绑定到Activity上 分析 一种优化启动的思路 介绍 今天，我们介绍一下app冷启动和热启动方式来实现app秒开的效果。那么，先来看看什么叫冷启动和热启动。 冷启动：指app被后台杀死后，在这个状态打开app，这种启动方式叫做冷启动。 热启动：指app没有被后台杀死，仍然在后台运行，通常我们再次去打开这个app，这种启动方式叫热启动。 那么，何为闪屏页呢？这个大家一般都知道，我们app也非常常见的。比如微信、QQ等等应用，你将这些应用清除掉它们的后台运行的情况下，再去打开。这时候会出现一个闪屏页，类似我们的背景页。这个页面停留的时间非常短，一般不会超过3秒，太久了就会使用户感觉这个app好卡的样子。 然后，我们看新建的一个项目，不做任何操作运行时会发现它在启动之时会有一个白屏的时间。那么，大部分app的解决方式就是我上面提到的闪屏页来替换白屏页。其实，也就是替换默认的activity的theme。我们看看白屏的效果（其实在我点下的瞬间，已经是白屏了。模拟器也许屏蔽了，在手机上非常直观） 白屏效果 为什么替换？这就是提升我们的用户体验了，可以发现我们白屏页显得非常的难看，而且用户可能会误以为这是app卡的结果造成的。如果我们换成了闪屏页，不仅可以为app添加属于自己的脸面，也可以造成一种app秒开的假象

旅程3：订单和注册限界上下文 CQRS之旅的第一站 “寓言家和鳄鱼是一样的，只是名字不同” --约翰·劳森 描述： 订单和注册上下文有一部分职责在会议预订的过程中，在此上下文中，一个人(注册者)可以购买特定会议的座位。还可以为已购买的座位分配与会者的名称(这在第5章“ 准备发布V1版本 ”中进行了描述)。 这是我们CQRS旅程的第一站，因此团队决定实现一个核心的、但自包含的系统部分——订单和注册。对与会者来说，注册过程必须尽可能地轻松。该流程必须确保业务客户能够预订到尽可能多的座位，并为他们提供灵活的，在会议上为不同类型的座位设置价格的功能。 因为这是团队处理的第一个限界上下文，所以我们还实现了系统的一些基础设施来支持领域域的功能。包括命令和事件消息总线以及聚合的持久化机制。 备注：本章描述的Contoso会议管理系统并不是该系统的最终版本。本此旅程描述的是一个过程，因此一些设计决策和实现细节在过程的后期会发生变化。这些变化将在后面的章节中描述。 在将来的某个旅程中，对这个限界上下文的改进计划包括支持等待列表(如果没有足够的座位可用，对座位的请求将放在等待列表中)，以及允许业务客户为座位类型设置各种类型的折扣。 备注：在这个版本中没有实现等待列表，但是社区成员正在开发这个特性和其他特性。任何带外发布和更新都将在“ CQRS之旅 ”网站上公布。 本章的工作术语定义：