我一直在做中小型项目，这些项目的业务逻辑相对比较简单，一直没有专门的把model层抽出来，因为如果面对的是node中间层，他已经把所有的业务逻辑梳理了一边并提供给我一个标准的接口，如果我把model层在抽出来的话，只是在api层上面再封装一下，本身没有任何意义，但是最近开发一个日历板组件改变了我之前的想法，
在开发日历板组件的时候，日历板组件需要面对不同的业务场景，但是这些业务场景在视图操作上是一致的，我针对这种情况的设计是：开发一个通用的、面向任何场景、不考虑具体业务场景的、输出数据尽量多且全、功能尽量丰富、定制化选项多的一个组件，在开发完这个组件之后，我又针对具体业务场景编写了一个日历板组件扩展库，该库可针对具体业务场景做适配，具体用法是：使用方先确定自己的业务场景，然后引入指定的扩展库，然后使用扩展库将业务数据转换成组件想要的格式，然后转递给组件，同样在接收组件输出的数据的时候，使用具体的扩展库的转换方法，将输出数据转换为具体业务场景想要的数据格式，这样做的好处是：
1：随着业务的不断迭代，组件本身不需要更改，只需要修改扩展库即可，除非是大的功能升级
2：通过扩展库的方式，日历板组件可以适配任何业务场景，因为只是增加一个扩展库而已
在这里 组件相当于视图层，而扩展库相当于中间层，具体的业务场景相当于model层（在这里 是api层），如果把这种设计模式扩展到项目开发中是什么样子的呢？
我们需要先熟悉一下react中容器组件与展示组件的区别：
展示组件：单纯的展示，封装一个具体的功能
容器组件：业务层与展示组件之间沟通的桥梁，主要负责数据转换（即将组件输出的标准数据转换为具体业务需要的数据，同时将业务数据转换为组件需要的标准组件）
然后，这还是没有涉及到model层，在讨论之前，我先按照我的理解 对小型项目、中兴项目、大型项目做一个定义
小型项目：小于5个页面，只是单纯的增删改查
中型项目：几十个页面，复杂的逻辑控制，包括鉴权、缓存、多角色功能、复杂业务场景
大型项目：几十几百个页面，多人合作，多模块等
所以在小型项目中，根本不存在model层，因为业务场景非常的简单，只是从api获取数据然后展示，
针对中型项目，其实是需要严格划分出model层，划分model的意义在于解耦 抽离，便于维护，我们需要找到项目中的变与不变，页面的更新频率是远远小于具体业务场景的更新频率的，甚至于如果我们的组件是功能丰富的，我们要做的仅仅是修改数据配置，所以我们把model层单独抽离出来，然后使用容器组件做展示组件与model层的衔接，容器组件负责数据转换，这样的话 我们只需要关注数据即可。
针对大型项目，不仅仅是要抽离出model层，还是要按模块解耦，就是最新的微前端方案
哪些东西可以抽出来作为model层？当我们在思考Model层的时候，我们的关注点需要从界面挪开，但是因为作为前端开发 关注点天然是界面，这已经形成了一种习惯，所以这是一个很困难的方式，但是我们还是要按照服务器端的思维来设计Model层，当我们设计Model层的时候，我们需要先熟悉业务，把业务熟悉之后，即可划分出对应的模块，然后根据具体业务场景 编写具体的业务函数。而model层的设计又是另外一个需要学习的地方。