首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >flutter中使用BloC模式

flutter中使用BloC模式

原创
作者头像
brzhang
修改2018-12-02 16:01:43
17.3K6
修改2018-12-02 16:01:43
举报
文章被收录于专栏:玩转全栈玩转全栈
业务逻辑组件
业务逻辑组件

什么是BloC模式?

BloC【Business Logic Component】模式是paolo soares 和 cong hui 在2018年Google dartconf上提出的,具体的视频你可以参考YouTube.

从视频中可以看到paolo soares用一个及其简单的例子阐述了传统写法的问题:

1、业务逻辑和UI组件糅合在一起。

2、不方便测试,不利于单独的测试业务逻辑部分。

3、不能更好的重用业务逻辑代码,体现在,如果网络请求的逻辑有所变动的话,加入这个业务功能被两个端(web、flutter)使用的话,是需要改动两个地方的。

基于上面出现的一些问题,paolo soares顺利的将我们重传统的开放方式,引入到了Bloc模式。

传统的开发方式
传统的开发方式

传统的开发方式,可以很明显的看出来,其中网络请求的代码和ui界面写了一起,日积月累,这里面的代码复杂度会随之增加,下面是改造之后的编写方式,将业务逻辑抽出来,放到了一个businessLogic中了。

改造之后的方式
改造之后的方式

可以看到改造之后,变得清晰多了,这个文件几乎就全部是UI构建的代码,所有的逻辑都抽到了businessLogic中了。做过android开发的小伙伴看到这个模式就一定会联想到MVP设计模式了吧,其中Presenter似乎就是干businessLogic的事情了。更具我自己的一点理解来看,实际上BloC设计模式,似乎和MVP没有什么本质区别,两种设计模式的最终目的就是为了把和UI糅合在一起的业务逻辑代码剥离开来,单独的抽取到一层中。

如何用BloC模式

BLoC Pattern
BLoC Pattern

上图是描述的是,组件的一些基本行为,【展示数据】,【发送事件】。在flutter中,实现BloC模式的精髓就是,

展示的数据从BloC中来,具体到了stream上,有了stream的到来,就可以使用StreamBuilder来构建ui了。

// TODO(ianh): remove unreachable code above once https://github.com/dart-lang/linter/issues/1141 is fixed
class StreamBuilder<T> extends StreamBuilderBase<T, AsyncSnapshot<T>> {
  /// Creates a new [StreamBuilder] that builds itself based on the latest
  /// snapshot of interaction with the specified [stream] and whose build
  /// strategy is given by [builder]. The [initialData] is used to create the
  /// initial snapshot. It is null by default.
  const StreamBuilder({
    Key key,
    this.initialData,
    Stream<T> stream,
    @required this.builder
  })
      : assert(builder != null),
        super(key: key, stream: stream);

发送事件丢给BloC处理,具体到了sink上。

/**
 * A generic destination for data.
 *
 * Multiple data values can be put into a sink, and when no more data is
 * available, the sink should be closed.
 *
 * This is a generic interface that other data receivers can implement.
 */
abstract class Sink<T> {
  /**
   * Adds [data] to the sink.
   *
   * Must not be called after a call to [close].
   */
  void add(T data);

  /**
   * Closes the sink.
   *
   * The [add] method must not be called after this method.
   *
   * Calling this method more than once is allowed, but does nothing.
   */
  void close();
}

恩,事件发送过去之后,onListen中就可以收到,并且识别出事件,进行相应的处理,之后,stream中产生了新的数据,于是,StreamBuilder又触发了UI的更新,整个流程就跑通了。

来一个简单的例子

UI部分

void main() => runApp(new MyApp());

class MyApp extends StatelessWidget {
 ///...
}

class CounterPage extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    final IncrementBloc bloc = BlocProvider.of<IncrementBloc>(context);

    return Scaffold(
      appBar: AppBar(title: Text('Stream version of the Counter App')),
      body: Center(
      ///注意这里,通过stream构建ui
        child: StreamBuilder<int>(
          stream: bloc.outCounter,
          initialData: 0,
          builder: (BuildContext context, AsyncSnapshot<int> snapshot){
            return Text('You hit me: ${snapshot.data} times');
          }
        ),
      ),
      floatingActionButton: FloatingActionButton(
        child: const Icon(Icons.add),
        onPressed: (){
        ///注意这里,事件发送
          bloc.incrementCounter.add(null);
        },
      ),
    );
  }
}

Bloc部分

class IncrementBloc{
  int _counter;

  //
  // Stream to handle the counter,第一组stream
  //
  StreamController<int> _counterController = StreamController<int>();
  StreamSink<int> get _inAdd => _counterController.sink;//这个sink用与给outCounter添加数据
  Stream<int> get outCounter => _counterController.stream;//这个就是ui需要使用的stream

  //
  // Stream to handle the action on the counter,第二组stream
  //
  StreamController _actionController = StreamController();
  StreamSink get incrementCounter => _actionController.sink;//这个暴露给外部,用户接受ui事件

  IncrementBloc(){
    _counter = 0;
    _actionController.stream.listen(_handleLogic);
  }

  void _handleLogic(data){
    _counter = _counter + 1;
    _inAdd.add(_counter);
  }
}

初次接触这种模式,你可能会稍感不适,没有任何关系,在心中把这个回路多跑即便,就清楚了,注意这里的BloC的设计上用到了两组stream,对,你没看错,是两组,两组形成了一个【闭环】,才能搞出这种【打法】。

因为第一组stream用户产生ui用的数据,第二组stream用户接受处理UI事件。

总结及个人建议

使用Bloc模式开发app的好处显而易见,大约有:

1、严重遵守了单一职责原则,代码解耦更好。

2、模块更加易于测试。

3、便面了setState的方式来触发build,可能性能更好,注意,只是可能,因为这也是大佬们说的,我并不太认可,实际上我认为,即便是使用streamBuilder,当stream有新的data时,也是触发了其包裹的组件走build的。

那么,你真的需要BloC模式吗?

1、个人觉得,非常简单的页面,使用BloC就有点过了,实际上像上面那个例子,点击次数计数,用StateFulWidget明显就是更优选择,使用BloC就有点为了模式而模式了。

2、用于不用BloC,要基于业务场景来考虑,个人觉得,对于多个UI共享一份数据的例子,就非常使用BloC模式,比如订单相关的页,购物车等等,因为订单状态的扭转,购物车物品同步,用户发送的事件相当多,这种如果使用BloC模式,显然会是目前来看的最优模式。

Redux相比大家也听过了,flutter中当然也是有的,那么,和Bloc有什么区别么?

1、个人觉得,并没有什么区别,都可以实现数据共享,大家也都能实现总线的功能,redux理解难度上,似乎还要比Bloc更加复杂点,因为他概念会多一些。

2、如果让我选择,我更加倾向于直接使用Bloc,最少的代码完成需求,比起引入一个库,话费的代价要少。

初学者的疑问

1、想bloc发送事件一定需要通过另外一个streamController么?答案是不一定,写成一个公开发送,直接操作那个数据相关的StreamController发送数据也可以,个人觉得这么写可能还更加简单呢?只是看自己以的业务逻辑吧。

2、必须要通过,final IncrementBloc bloc = BlocProvider.of<IncrementBloc>(context);获取bloc么?

我的回答是,必须有一个地方是的,就像弹吉他一样,根弦需要,其他的不需要而且不能需要,因为如果次级页面也通过这种方式获取的话,那他销毁时,dispose被回调,这个bloc也就销毁了,一级页面的bloc也就不能用了,这其实也是一个坑,很容就掉进去了,所以,区分什么时候通过final IncrementBloc bloc = BlocProvider.of<IncrementBloc>(context);获取,什么时候通过参数传递的方式传递过去,还是很重要的。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 什么是BloC模式?
  • 如何用BloC模式
  • 来一个简单的例子
  • 总结及个人建议
  • 初学者的疑问
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档