项目结构优化设计之smv架构

我的项目经历了三次结构性变化

第一次：单module+mvc结构。

appmodule+mvc.png

随着项目业务的拓展，项目分包的差异化变迁以及团队人员的扩充，传统的单module方式
明显已经不再适应团队和项目了。基于这种情况，我开始着手对项目进行结构调整，就是下方的组件化模式。

第二次：组件化+mvp结构

根据根据业务进行组件划分，单人维护业务module，单module 运行、开发、调试；提高工作效率。
具体结构如下图

组件化.png

发展到现在，这个结构还能支持团队和项目需要，但是造成了分包维护的困难，对工作质量的上升也遇到了瓶颈。
基于此我进行了第三次结构设计；顺利解决了分包维护，多人开发，分包发布的困难并满足了项目和团队需要；

第三次：smv 结构
在组件化和mvp的架构思想基础上，根据实际需要，我对组件化+mvp的结构进行了一次升级。具体项目结构如图：

smv+组件化.png

为了区分 组件化+mvp 的架构，我把整体架构称为：smv架构。具体解释一下具体功能：
组件化不用过多的解释了，就是对具有不同功能的业务组件进行module封装；
主要说一下smv结构设计：

module结构图：

businessModule.png

view结构图：

view.png

s -> service 服务
m -> businessmodule 数据
v -> view 视图

service是基础服务；
基础服务包含：网络工具，图片工具，自定义view等其他工具；
可以支持多个业务module；

businessmodule是业务服务。
业务服务包含：具体业务功能，包含业务数据处理，业务逻辑处理；不涉及ui和交互；
可以支持多个业务分包应用；

view是视图
视图包含：各业务的ui和交互。
依赖于业务服务，可以定制多个 ui/功能差异化分包，自由组合，自由拆分。

总思路：基础服务 + 业务服务 + ui交互 + 分包组装

使用：
view层持有businessmodule依赖。
businessmodule持有service依赖
view为分包表现层。

解决问题：
1、从结构上实现ui和业务的解耦。
2、技能满足单人开发维护，也能满足多人发开维护。
3、适用于单业务分角色分包模式。
4、减小开发和维护压力。
5、方便单元测试，业务功能和ui交互均可单独测试。
6、使性能优化，交互优化工作更简单。

smv结合mvp使用案例，后续更新...