EventBus

vue组件之间的通信有很多种方式，最常用到的就是父子组件之间的传值，但是当项目工程比较大的时候，就会出现兄弟组件之间的传值，跨级组件之间的传值。不可否认，这些都可以类似父子组件一级一级的转换传递，但是当项目比较大，功能比较复杂的时候，就会变得比较冗余，代码不利于维护；这时候可能会有很多人使用到vuex，但是如果项目中多个组件共享状态比较少，项目比较小，并且全局状态比较少,好像就没有使用vuex来管理数据的必要。 一、中央事件总线（eventBus） 主要是通过在要相互通信的兄弟组件之中，都注册引入一个新的vue实例，然后通过分别调用这个实例的事件触发和监听来实现通信和参数传递，也就是我们常说的bus车事件。 1、首先，全局注册一个新的vue实例，可以放在我们常用的vue项目文件中 js/event-bus.js import Vue from 'vue' export default new Vue() 2、如果不想全局引用可以，在使用的vue文件里使用，举个例子：contentLeft.vue,contentRight.vue 需要将contentLeft.vue与contentRight.vue互相通信 contentLeft.vue <template> <div> {{message}} <button @click="handleClick">test</button>

本篇是“事件驱动的微服务”系列的第二篇，主要讲述事件驱动设计。如果想要了解总体设计，请看第一篇 "事件驱动的微服务-总体设计" 程序流程 我们通过一个具体的例子来讲解事件驱动设计。 本文中的程序有两个微服务，一个是订单服务（Order Service）， 另一个是支付服务（Payment Service）。用户调用订单服务的用例createOrder（）来创建订单，创建之后的订单暂时还没有支付信息，订单服务然后发布命令（Command）给支付服务，支付服务完成支付，发送支付完成（Payment Created）消息。订单服务收到消息（Event），在Order表里增加Payment_Id并修改订单状态为“已付款”。 下面就是组件图： 事件处理 事件分成内部事件和外部事件，内部事件是存在于一个微服务内部的事件，不与其他微服务共享。如果用DDD的语言来描述就是在有界上下文（Bounded Context）内的域事件（Domain Event）。外部事件是从一个微服务发布，而被其他微服务接收的事件。如果用DDD的语言来描述就是在不同有界上下文（Bounded Context）之间传送的域事件（Domain Event）。这两种事件的处理方式不同。 内部事件： 对于内部事件的处理早已有了成熟的方法，它的基本思路是创建一个事件总线（Event Bus），由它来监听事件

【推荐阅读】微服务还能火多久？>>> 格式化日期时间组件：https: // pub.dev/packages/date_format 日期选择组件：https: // pub.dev/packages/flutter_cupertino_date_picker 轮播图组件：https: // pub.dev/packages/flutter_swiper showToast(弹窗提示)：https: // pub.dev/packages/fluttertoast 网络请求(Dio)：https: // pub.dev/packages/dio 解析html数据：https: // pub.dev/packages/flutter_html 加载远程web页面：https: // pub.dev/packages/flutter_inappbrowser 获取设备信息：https: // pub.dev/packages/device_info 实现用高德定位：https: // pub.dev/packages/amap_location 相机拍照 和相册选择：https: // pub.dev/packages/image_picker 视频播放： https: // pub.dev/packages/video_playe (在 Flutter 里官方提供了一个 video

【推荐阅读】微服务还能火多久？>>> 　　Web前端重点技能是什么？Vue相关面试题有哪些？Vue是一套构建用户界面的渐进式框架，具有简单易用、性能好、前后端分离等优势，是Web前端工程师工作的好帮手，也是企业选拔人才时考察的重点技能。接下来千锋小编就给大家分享一些Vue相关的面试题，帮助大家提升竞争力。 　　你对Vue生命周期的理解? 　　Vue实例有一个完整的生命周期，也就是从开始创建、初始化数据、编译模版、挂载Dom -> 渲染、更新 -> 渲染、卸载等一系列过程，我们称这是Vue的生命周期。 　　Vue组件如何通信? 　　Vue组件通信的方法如下: 　　props $emit+v-on: 通过props将数据自上而下传递，而通过$emit和v-on来向上传递信息。 　　EventBus: 通过EventBus进行信息的发布与订阅; 　　vuex: 是全局数据管理库，可以通过vuex管理全局的数据流; 　　$attrs $listeners: Vue2.4中加入的$attrs/$listeners可以进行跨级的组件通信; 　　provide/inject：以允许一个祖先组件向其所有子孙后代注入一个依赖，不论组件层次有多深，并在起上下游关系成立的时间里始终生效，这成为了跨组件通信的基础。 　　Vue如何实现双向绑定? 　　利用Object

【今日推荐】：为什么一到面试就懵逼！>>> 如何将 .NetFramework WebApi 按业务拆分成多个模块 在 .NetFramework 中使用 WebApi ，在不讨论 微服务 的模式下，大部分都是以层来拆分库的 : 基础设施 数据存储层 服务层 WeApi 层 一些其它的功能库 项目结构可能会像下面这样子 有些人可能会将其中的 数据存储层、服务层 按业务功能进行垂直拆分， 但是到了 WebApi 这层，就不得不把所向所有业务功能的 Controller 都堆在这儿了。 随着业务的堆积，WebApi 这层的代码量越来越大，耦合性也越来越强，越来越难维护。 … …… ……… ………… 这时候，微服务 就出现了。 可是，微服务 给系统所带来的复杂程度是极高的， 在某些场景下，转 微服务 可以很好的解决这些问题，但是又会带来更多的新问题， 所以我们希望有一种模式，即能像 微服务 那样对代码进行垂直切分，又能保持简单易维护的 单体应用程序 模式。 打算在 单体应用程序 中解决这种趋于 臃肿 问题，我们可以借鉴 微服务 那种 按业务垂直拆分 的思想。 但是与 微服务 不同是，它依然是单启动程序，这个启动程序能够组织出散落在各个模块中的所有 WebApi 并暴露给外部。 换个角度思考，其实就是将业务 模块化 。 微软维护的 Ochard 框架很好的实现了这些功能，但是使用

【今日推荐】：为什么一到面试就懵逼！>>> 监听者模式 是一种比较常见的设计模式。 在日常的开发中，我们所使用的 事件 就是一种符合 监听者模式 的功能。 对 监听者模式 还不太明白的同学可以通过 WinForm 开发来理解这一概念。 在 WinForm 模式下，事件的使用率是非常高的，窗体中的每一个 Controller 都提供了大量的事件，诸如 Click 、 DoubleClick 、 Load 、 Focus 等等。 为什么会这样设计呢？ 因为，当你编写一个与业务无关 控件 的时候，你应当只编写与 显示 相关的代码，以 Button 为例。 编写一个 Button 关心的是如何画出符合尺寸大小的按钮，什么颜色，什么边框，字的位置。至于按下这个按钮需要执行什么，你在编写 Button 还不知道，必须交给 外面 去处理。 所以使用 事件 将点击的信号发送出去，交给外面去处理。 在我们编写业务的时候会用到事件吗? 很少有人会在业务代码中使用 事件 ，一个常见的数据操作流程如下： 前台通过 Http 请求提交数据 通过 WebApi 框架内部的调度，执行某个 Controller 上的某个 Method 开发人员校验提交数据的有效性。可能是通过直接在 Controller 中实现，也可能通过 AOP 等形式实现 将数据交由服务层处理 服务层经一定处理，将数据交由持久层处理

今天推送一篇关于 Android 架构的最佳实践项目。 文章目录一览 前言 面向标准化开发已成现实 本文的目标 Jetpack Lifecycle Lifecycle 存在前的混沌世界 Lifecycle 为什么能解决上述这些问题？ Jetpack LiveData LiveData 存在前的混沌世界 LiveData 为什么能解决上述这些问题？ LiveData 有个坑需要注意 Jetpack ViewModel ViewModel 存在前的混沌世界 ViewModel 为什么能做到这几点？ Jetpack DataBinding DataBinding 存在前的混沌世界 DataBinding 就是来解决这些问题 综上 Jetpack Lifecycle Lifecycle 的存在，主要是为了解决 生命周期管理 的一致性问题 Lifecycle 存在前的混沌世界 在 Lifecycle 面市前，生命周期管理 纯靠手工维持，这样就容易滋生大量的一致性问题。 例如跨页面共享的 GpsManager 组件，在每个依赖它的 Activity 的 onResume 和 onPause 中都需要 手工 激活、解绑 和 叫停。 那么 随着 Activity 的增多，这种手工操作 埋下的一致性隐患 就会指数级增长： 一方面，凡是手工维持的，开发者容易疏忽，特别是工作交接给其他同事时

由于这段时间公司比较闲，就对vue 中的一些模糊的点做了一些加强，突然就想到了常挂在嘴边兄弟组件传值 我理解的兄弟组件的传值是可以路由由传值的，比如我从 http://localhost:8080/ login 里面的值可以传递到 http://localhost:8080/home 这个页面的 于是我是www.baidu.com 了一番,没错，跟我想象一样的，可以进行页面传值， 于是呼我就跟着百度一番操作 像这样： 于是我建了一个 bus.js import Vue from 'vue' export const EventBus = new Vue() 像这样： 于是我在我的 login.vue 里面绑定了一个 $emit import { EventBus } from '../../bus' clickLgin() { console.log(EventBus) EventBus.$emit('add', '123456789') } 　　 像这样： 于是我在我的home.vue 添加 $on 　　 import { EventBus } from '../../bus' created() { EventBus.$on('add', target => { console.log(target, '222') }) } 　　 　　到这儿该结束了，可以愉快的拿到 login

1 写这篇博客的初衷 首先一句话概括：我想把这几个月做的事情记录下来，并且希望尽量详细，希望读者读了这篇文章能够知道项目进行模块化，项目改业务框架可能会遇到哪些问题，具体每个步骤都做什么，而不是大致的了解。 现在很多人都在谈模块化，网上有一大堆的博客实践都在讲这个。很多谈的只是模块与模块之间的解耦，并且大部分讲的是通过router路由进行解耦，其他谈的不多，而且不乏泛泛而谈。但将一个app真正做到解耦，运行。需要解决的事情远远不止解耦。业务架构、进程间通信、资源等处理、解耦方式等都需要解决。恰好对于猫眼模块化整个过程的实施，从头到尾，分析解决各种问题，我陆陆续续的做了几个月。猫眼app的历史版本是一个耦合度很高的一个工程。从这样的一个历史版本到最终的各个业务模块能够独立运行并且能够做进程间通信，会涉及到各个方面的解耦和一些其他东西。我今天我就以该app为例（其他的app进行解耦可能会遇到不同的问题，这点注意一下），完整的讲下猫眼模块化的整个过程。每一个方面没有照搬网络的一些做法，而是分析对比，采用更好的设计方式。比如解耦使用serviceloader，而不是路由进行；比如架构使用更适合我们业务的一种带生命周期的mvp变种。我还会说下具体的花费时间和一些经验，这样大家以后做模块时也心中有数。（提示一下，其实模块化过程所涉及的东西除了文章提及的还有很多。有些未提及，是因为之前已经完成

写在前面 好久好久没写了，最近刚换了工作，花了几天的时候熟悉了项目，接着就是功能的完善，随后就是对新项目的基础架构搭建。 看过Po主博客的都知道，Po主一直致力于推广.Net Core在微服务架构上的实践，包括从去年年底开始也正在写一本关于此类的书（目前还在写的阶段，不便公布）。换新东家的目的也是如此，公司是个集团公司，但楼主负责的项目还不是很大，So，微服务架构可能现阶段还无法实现。 但Po主一心向往微服务架构，所以我在搭建基础架构的时候，想到了一种过度架构方式，也不知道如何称呼，随心所欲称之为：单体服务架构（Single Service Architecture-简称SSA） 什么是单体服务架构 什么是单体服务架构呢？总的来说，架构看上去类似于微服务架构，但它只包含了一个服务，我们的业务逻辑统统放到这一个服务来，简单画个图： 怎么样，简单吧，我们来对比下eShop的架构图： 如何，看出什么了吗？我们的架构去除了Api gateway，去除了EventBus，把各个服务结合在了一起，形成了一个单一的服务，所以我称它为单体服务架构。 为什么需要单体服务架构 可能大家好奇，为什么需要单体服务架构（后称SSA）呢？如果大家了解过微服务架构的话，应该听说过康威定理吧，或者说听说过“微服务架构不是银弹”类似的话吧，概论就是并不是所有企业所有项目都适合微服务架构。但在技术热潮之中