React语境下的Model, Controller和Service

我在2年前开始研究和撰写自己的框架,基于react作为视图层驱动,我开发了Nautil。Nautil是一款目标为实现跨端开发同构的前端开发框架。我在自己的博客中,专门去阐述过跨端复用分层的文章。本文,我主要讨论的是,react语境下,抛开视图层,Model, Controller和Service如何进行编程。

前端建模

前端数据模型,主要是为确保在前端程序中,业务对象在行为上的准确性。数据模型和领域模型有一定的差别,领域模型更多是从理念层面指导我们设计,而数据模型则是在具体层面进行技术实施。领域模型是思想,数据模型是代码。

前端语境下,我们需要通过模型来确保用户交互过程中,所触发的动作,数据的变化,都在一个具体的框定下发生。而用于框定的,就是模型层。我们在设计模型时,遵循DDD的设计思想,模型本身并不需要关注它会被如何使用,也就是它的外部环境。模型只需要关注自身的描述,是否完整的反应了业务对象的面貌。

具体怎么去建模呢?Nautil提供了基于Tyshemo的建模基类。

import { Model } from 'nautil'

class PersonModel extends Model {
  schema() {
    const name = { default: '', type: String }
    const age = { default: 0, type: Number }
    return { name, age }
  }
}

前端建模的原则主要有:

  1. 反应,且只反应业务对象(Entity)的内涵。简单说就是模型是最抽象的纯描述系统,它包含一定的逻辑,但是这些逻辑,仅仅是为了描述清楚该业务对象的属性逻辑,而和流转逻辑交互逻辑完全没有关系
  2. 明确业务对象的区别边界。在实际开发中,Entity A和Entity B可能存在90%的相同部分,但剩下的10%就是它们的边界。A和B是否属于同一个对象,或者属于同一种对象下的不同对象,都需要在开发中明确,而不能忽视10%的差异,把A和B使用一个Entity表示。
  3. 理解透彻字段之间的联系。实际开发中,两个字段不可避免可能存在联系,比如a依赖b,b的变化会引起a的变化,比如在校验时,c的校验逻辑收到d的影响……
  4. 理解透彻业务对象父子关系。实际开发中,业务对象包含关系是可能存在的,例如父对象A,同时包含了子对象B、C,且B的a字段校验逻辑,受到C的b字段的影响,此时应该在A中对这些联系加以约束,而非直接在B或C中进行修改。

另外,在前端语境下,Model实例是响应式的。当模型实例的字段/属性值发生变化时,可触发一定的执行逻辑,这主要帮助我们驱动视图的更新,这个能力是必须的,但是不属于领域模型的设计范畴,是前端的设计需求。

控制器到底控制什么?

控制器主要控制的是对用户的响应。当用户在界面上进行操作时,会产生特定的事件。这些事件需要被控制,并转化为实际的业务流转逻辑。这里的事件是指交互事件,而非领域事件。如何区分呢?简单举例,“用户点击了一个button,产生了一个click事件”这是交互事件,“当订单总额达到100元时,检查是否存在代金券,并在总额中减去代金券的面额”这里“达到100元”是领域事件。虽然这两种事件概念上差别巨大,但是它们发生的过程,可能是在一起的。控制器控制的是交互事件,而领域事件我将把它丢到服务中管理。

在传统react开发中,处理事件非常粗暴,就是一个类似DOM事件回调函数的方式进行撰写。但是,在分层业务系统中,我们不能这么粗暴。我们需要将用户的交互事件收集起来,根据事件的类型,以及我们所规定某些逻辑,合理的处理这些事件,并且根据这个事件的结果,处理模型实例上的值。这个过程就是从Event到Model的过程。

前文提到,我们可以订阅Model实例的属性值变化来触发视图层变化。但是,我们也可以在控制器层通过控制器内部代码来触发视图层变化,而不是订阅Model,让Model的变化触发视图层变化。我们来看一个例子:

class ShoppingController extends Controller {
  static shoppingcart = Shoppingcart
  static increase$(stream) {
    stream.pipe(
      debounceTime(500), // 点击按钮有500ms的debounce
      map(e => e.target.getAttribute('data-good-id')), // 得到goodId
    ).subscribe((goodId) => {
      this.shoppingcart.increase(goodId) // 将该goodId传入Shoppingcart实例,模型内自动计算价格
      this.rerender() // 我们可以自己实现一个方法,实现视图的更新
    }) // 我们可以通过修改原型链方法的方式,修改subscribe方法,让它在每次执行完成之后,都会去触发视图更新
  }

  IncreaseButton() {
    return <Button onHit={this.increase$}>+</Button>
  }
}

上面这种文件写法,你在react应用中应该从来没有写过,但这是Nautil框架的写法。Nautil中使用rxjs作为事件流管理工具,内置组件天生支持事件绑定到stream上。上面这段代码中,onHit={this.increase$} 表示当用户点击这个按钮的时候,会触发increase$这个流的一次发射。完成这个绑定之后,就没有其他事情需要做了。关于点击这个按钮之后会发生什么事情,那完全变成了rxjs的编程模式。rxjs的管道编程可以完全脱离视图层,例如,上面的pipe的部分,仍然是在处理交互的逻辑,我们可以把这部分再拆出来,交互的pipe不要和业务的pipe混在一起,我们可以把这部分pipe进行转移:

<Button onHit={[debounceTime(500), map(e => e.target.getAttribute('data-good-id')), this.increase$]}>+</Button>

我把交互相关的pipe转移到视图相关的代码部分去,这也是Nautil支持的一种写法。通过这个转移,那么在上面的increase$中,只有存数据操作相关的代码。

控制器在Nautil中,实际上是一个集中管理器,它把有关一个业务相关的模型、视图、服务集中在一个地方进行管理,内部使用this调用自己内部的东西,并无法调用外部的东西,区分了一个业务的边界。

控制器的实例将会被视图层,也就是我们熟悉的react组件中去使用,对于组件而言,它只使用控制器暴露出来的视图层接口,而不应该使用非视图相关的东西。例如:

// 购买页面
export default class ShoppingPage extends React.Component {
  controller = new ShoppingController()

  render() {
    const { IncreaseButton } = this.controller
    return (
      ...
      <IncreaseButton />
      ...
    )
  }
}

虽然控制器在组件实例中被调用,但是实际上它们是隔离的,react组件其实只是一个布局工具,而没有任何对业务逻辑的操作。完成这种分离之后,视图层看上去被割裂了,一部分在这里,一部分在那里,但是如果站在业务的角度去看,一个业务的边界清晰了,这里面有舍有得,具体怎样好,还需要在实践中摸索。

服务,单例

在大部分编程场景下,服务其实是一个工厂,它所提供的方法仅承接辅助处理能力,不承接核心业务逻辑,但又稍有不同,服务是为特定业务创建的方法聚合,它是有边界的,但它的内部又是强相关的,一般不提倡服务有状态,但是我们可以让服务拥有一定的状态。

前端编程领域,与服务端进行交互,完成数据接口的读写的这一层,大多数情况下也被称为服务层,因为它主要提供数据接口交互相关方法。而你可以看到,这些方法它们一般来讲,本身并不拥有状态,但是,当我们需要在请求接口时,实现缓存、debounce、请求频次控制时,又可以增加一些细微的状态来控制。

在Nautil中,我将服务设计为单例,当然,它可以被实例化后使用,但如果按照规定用法,每次获取的都是全局单例。单例的好处是,整个应用共享一个单例,这样可以在某些场景下做到状态处理,以解决某些特定的场景。例如上文提到的请求逻辑,如果在两个Controller中都触发了某一个接口请求,那么很显然,我们应该只创建一个请求,并将结果返回给两个请求者。我们看代码:

class ShoppingService extends Service {
  requestApi(url) {
    const deferer = this._requestApiDeferer || fetch(url).finally(() => { delete this._requestApiDeferer })
    return this._requestApiDeferer = deferer
  }
}

在Controller中使用它

class ShoppingController extends Controller {
  static shoppingService = ShoppingService
  
  getGoods() {
    this.shoppingService.requestApi('...').then(res => res.data).then((data) => {
      this.goods = data
      this.rerender()
    })
  }

  GoodList() {
    useEffect(() => {
      this.getGoods()
    }, [])
    return (
      <ul>
        <Each of={this.goods} render={(good) => 
          <li>{good.name}<li>
        } />
      </ul>
    )
  }
}

由于GoodList可能会在多个地方被同时使用,比如一个页面有两处都用到了,如果不做缓存处理,那么就会导致发起两次ajax请求,但是如上处理之后,就可以防止同一时刻两个相同请求被发起。而由于这个缓存机制是在Service中做的,所以对于Controller而言,是无感的,未来Service中还可以进行修改,但是它要得到的效果对于Controller而言,是一致的。

而除了ShoppingController,可能还有GoodController会用到ShoppingService的这个接口,也就是说,会出现两个控制器都调用同一个接口的情况。而由于单例模式的存在,不同控制器其实最终得到的是同一个ShoppingService实例,因此,还是只会有一个请求发起。

和Model不同,Service 一般不保持状态,因此,也就不需要响应式的能力。服务的任何方法,大多数工厂方法,不会触发某种响应,因此,在实际编程中,我们自由的选择是使用全局的单例服务,还是自己实例化一个服务来使用。

结语

在前端领域,特别是react的语境下,很少有人会去想本文提到的这些东西。本文所设计的这些方式,本质上还是遵循一个思想,即“高内聚,低耦合”,在不同的对象之间,划清界限,几乎完全解耦,当需要将它们联系起来时,又去寻找可以把它们聚合起来的对象。这是我在前端分层实践中的总结,不一定对所有人有用,但如果你在编写前端应用中遇到类似问题,不妨参考本文的思路。

2021-01-14 314

为价值买单

本文价值3.14RMB