在一次表单重构中，我逐渐意识到，在数据和【版权所有】唐霜 www.tangshuang.net【版权所有】唐霜 www.tangshuang.netUI分开的前端开发模式中，UI和数据越来【本文受版权保护】未经授权，禁止复制转载。越需要解耦，UI要完完全全和数据本身无关【本文首发于唐霜的博客】【版权所有，侵权必究】，做到无状态，做到完全靠数据驱动，并且提【原创内容，转载请注明出处】原创内容，盗版必究。供响应接口（更新UI的接口）。而数据层面【关注微信公众号：wwwtangshuangnet】【关注微信公众号：wwwtangshuangnet】，如果考虑到自身将被用于渲染，那么就要配本文作者：唐霜，转载请注明出处。【本文首发于唐霜的博客】置一个驱动器，将原始的数据结构转化为便于原创内容，盗版必究。【版权所有】唐霜 www.tangshuang.netUI使用的数据结构，这就是独立于UI的数著作权归作者所有，禁止商业用途转载。未经授权，禁止复制转载。据模型驱动器。

拿表单来说，市面上有一些基于jquery著作权归作者所有，禁止商业用途转载。【作者：唐霜】的表单框架，虽然说是框架，实际上，还是一原创内容，盗版必究。【版权所有，侵权必究】套基于js配置的ui组件，并非真正意义上【本文受版权保护】转载请注明出处：www.tangshuang.net的框架。而我的思考是，我们同一套表单，它本文版权归作者所有，未经授权不得转载。【作者：唐霜】背后的业务逻辑、数据提交的验证、编辑时的本文作者：唐霜，转载请注明出处。原创内容，盗版必究。数据回溯等等问题，也就是脱离了UI层面的【版权所有】唐霜 www.tangshuang.net【原创不易，请尊重版权】其他逻辑问题，都可以抽象出来。现在的开发【原创不易，请尊重版权】【本文首发于唐霜的博客】全部是多端开发，同一个表单，在UI界面上【本文首发于唐霜的博客】【本文受版权保护】可能不同，使用的UI技术也可能不同，例如【版权所有】唐霜 www.tangshuang.net【原创内容，转载请注明出处】在公众号网页和在小程序中，甚至在Reac原创内容，盗版必究。著作权归作者所有，禁止商业用途转载。tNative构建的原生app中，他们抛【作者：唐霜】未经授权，禁止复制转载。开UI、交互层面的东西，背后的业务逻辑几未经授权，禁止复制转载。本文版权归作者所有，未经授权不得转载。乎是一摸一样的，为什么不可以共享？而且这【版权所有】唐霜 www.tangshuang.net本文作者：唐霜，转载请注明出处。三种场景，背后都支持js原生的计算能力和著作权归作者所有，禁止商业用途转载。【版权所有】唐霜 www.tangshuang.net语言特性，所以，很明显是一定可以共享的，【原创不易，请尊重版权】【转载请注明来源】所不同的是，在将模型和UI框架进行拼接时著作权归作者所有，禁止商业用途转载。转载请注明出处：www.tangshuang.net，拼接方式不同。

表单模型只是一个例子。这种将模型抽离出U本文作者：唐霜，转载请注明出处。转载请注明出处：www.tangshuang.netI的方案，适用于大部分带有业务逻辑的中后【版权所有】唐霜 www.tangshuang.net【访问 www.tangshuang.net 获取更多精彩内容】台应用中，在都使用了web技术的前提下，原创内容，盗版必究。著作权归作者所有，禁止商业用途转载。想多端共享同一套业务逻辑，就应该用这种思【作者：唐霜】本文版权归作者所有，未经授权不得转载。路去写。

现在的问题是，有没有一套完整方案（框架）本文作者：唐霜，转载请注明出处。【本文首发于唐霜的博客】，去像React那样，编写模型。我认为还【转载请注明来源】【访问 www.tangshuang.net 获取更多精彩内容】没有，或者说，还没有一个UI框架是基于这本文作者：唐霜，转载请注明出处。著作权归作者所有，禁止商业用途转载。种考虑去实现的，因此，也就没有模型框架可【未经授权禁止转载】【作者：唐霜】以被应用到实际开发中。如果有一种UI框架【转载请注明来源】未经授权，禁止复制转载。（特别是React），可以基于“模型-视【作者：唐霜】【关注微信公众号：wwwtangshuangnet】图”的方式去开发自己，那么就更有利于模型著作权归作者所有，禁止商业用途转载。【版权所有】唐霜 www.tangshuang.net框架的出现。就目前而言，最接近这种形态的【访问 www.tangshuang.net 获取更多精彩内容】【版权所有】唐霜 www.tangshuang.net是rxjs作为模型框架，react作为U未经授权，禁止复制转载。未经授权，禁止复制转载。I框架。