为什么我不再使用MVC框架？( 五 ) _MVC框架

文章插图
图7：“修改地址”的实现
模式中的元素，包括Action和Model，可以进行自由地组合：
函数组合
data’ = A(B(data))
端组合（Peer）（相同的数据集可以提交给两个Model）
M1.present(data’)
M2.present(data’)
父子组合（父Model控制的数据集提交给子Model）
M1.present(data’,M2)
function present(data, child) {
// 执行更新
…
// 同步Model
child.present(c(data))
}
发布/订阅组合
M1.on(“topic”, present )
M2.on(“topic”, present )
或
M1.on(“data”, present )
M2.on(“data”, present )
有些架构师可能会考虑到System of Record和Systems of Engagement，这种模式有助于明确这两层的接口（图8），Model会负责与systems of record的交互。

文章插图
图8：SAM组合模型
整个模式本身也是可以进行组合的，我们可以实现运行在浏览器中的SAM实例，使其支持类似于向导（wizard）的行为（如ToDo应用），它会与服务器端的SAM进行交互：

文章插图
图9：SAM实例组合
请注意，里层的SAM实例是作为状态表述的一部分进行传送的，这个状态表述是由外层的实例所生成的。
会话检查应该在Action触发之前进行（图10）。SAM能够启用一项很有意思的组合，在将数据提交给Model之前，View可以调用一个第三方的Action，并且要为其提供一个token和指向系统Action的回调，这个第三方Action会进行授权并校验该调用的合法性。

文章插图
图10：借助SAM实现会话管理
从CQRS的角度来讲，这个模式没有对查询（Query）和命令（Command）做特殊的区分，但是底层的实现需要进行这种区分。搜索或查询“Action”只是简单地传递一组参数到Model中。我们可以采用某种约定（如下划线前缀）来区分查询和命令，或者我们可以在Model上使用两个不同的present方法：
{ _name : ‘/^[a]$/i’ } // 名字以A或a开头{ _customerId: ‘123’ } // id=123的customer
Model将会执行必要的操作以匹配查询，更新其内容并触发View的渲染。类似的约定可以用于创建、更新或删除Model中的元素。在将Action的输出传递给Model方面，我们可以实现多种方式（数据集、事件、Action……）。每种方式都会有其优势和不足，最终这取决于个人偏好。我更喜欢数据集的方式。
在异常方面，与React类似，我们预期Model会以属性值的形式保存异常信息（这些属性值可能是由Action提交的，也可能是CRUD操作返回的）。在渲染状态表述的时候，会用到属性值，以展现异常信息。
在缓存方面，SAM在状态表述层提供了缓存的选项。直观上来看，缓存这些状态表述函数的结果能够实现更高的命中率，因为我们现在是在组件/状态层触发缓存，而不是在Action/响应层。
该模式的反应型和函数式结构使得功能重放（replay）和单元测试变得非常容易。
SAM模式完全改变了前端架构的范式，因为根据TLA+的基础理念，业务逻辑可以清晰地描述为：

Action是纯函数
CRUD操作放在Model中
状态控制自动化的Action

作为API的设计者，从我的角度来讲，这种模式将API设计的责任推到了服务器端，在View和Model之间保持了最小的契约。
Action作为纯函数，能够跨Model重用，只要某个Model能够接受Action所对应的输出即可。我们可以期望Action库、主题（状态表述）甚至Model能够繁荣发展起来，因为它们现在能够独立地进行组合。
借助SAM模式，微服务能够非常自然地支撑Model 。像Hivepod.io这样的框架能够插入进来，就像它本来就在这层似得。
最为重要的是，这种模式像React一样，不需要任何的数据绑定或模板。
随着时间的推移，我希望能够推动浏览器永久添加虚拟DOM的特性，新的状态表述能够通过专有API直接进行处理。
我发现这个旅程将会带来一定的革新性：在过去的几十年中，面向对象似乎无处不在，但它已经一去不返了。我现在只能按照反应型和函数式来进行思考。我借助SAM所构建的东西及其构建速度都是前所未有的。另外，我能够关注于API和服务的设计，它们不再遵循由前端决定的模式。