看到这个题目很奇怪吧,网站技术开发跟乐高有毛线关系? 其实是这样的,最近和我们的后台技术一直有个争论,关于业务层的资源合并放在哪块做,谁来做的问题! 当然这是有史以来一直争论的话题。 这么多年看到资源combo放到各种地方的:
1、 数据库层
a、视图合并
b、存储过程 (这里还混有业务逻辑部分)
2、 后端开发 - 组合接口
3、 前端页面 - graphql 提供灵活的协议
我认为的乐高模型是这样的:
1、 乐高有最基础的标准件,也就是可以用来拼装成各种各样作品的零件。(对应API的Core的最小粒度接口)
每个标准件是不同的,但是它们有个共同的特征,提供公化、母化或者公母混合体
PS:(最近买HDMI转DVI转接头的感触,所以这样描述,虽然有点那个啥)
这样设计的好处是可以和其他的标准件大部分情况下可以拼接到一起。
我认为这样的设计风格奠定了乐高灵活多变的基础。
见附图1,2,3
2、由乐高标准件拼接而成的独立作品,例如拼装的吊车、小汽车。(对应API的资源Combo接口)
见附图4
3、孩子使用这些拼接完成不同的独立作品来进行他玩的场景游戏。
利用做好的吊车去吊做好的小汽车什么的。(对应网站开发的终端,实际的业务场景,用combo好的API来进行实际业务的开发)
见附图5
附图1:
附图2:
附图3:
拼合体:
附图4:
这样可以比较形象的描述前后端程序员争论combo接口的必要性的问题。
业务场景:(这个图不太形象,没找到更好的)
附图5:
结论:
combo接口肯定是必要的,那么这一块的投入和根据不同的业务场景需要提供多少comboAPI就要实际讨论了。
有兴趣可以找我讨论: 25018238@qq.com