Model,View,Presenter,Control
架构心得:
- 代码层面,工程要切割细碎,功能要复用,对于界面,最好以界面元素划分,不要以页面功能划分xml界面。
- 使用activity + fragment,这样activity最为视图的顶层,xml布局文件中只用flamelayout作为fragment的容器,fragment界面如果有相同元素的组件使用,根据界面使用的组件命名xml布局文件,复用相同元素的xml。
- 对于页面布局的View,使用BaseView,findView之类的通过fragment持有BaseView对象来是实现,对view操作的抽象和共用
Package层级
- model(模型集合)
- event(事件模型集合)
- entity(实体模型集合)
- object(实体集合)
- property(实体类属性集合)
- ObjectUrlResponse.class(实体网络请求类)
- ObjectDao.class(实体类数据操作类)
- ObjectFiled.class(实体类字段类)
- ObjectEntity.class(实体类)
- property(实体类属性集合)
- object(实体集合)
- view(页面集合)
- activity
- fragment
- provider(xml布局)
- ObjectProvider.class
- control
- adapter
- manager(下载队列)
- loader(图片的loader)
- response(实体类url json解析)
- taker(http/https)
- AsyncResourceTaker.class(异步)
- SyncResourceTaker.class(同步)
- Application.class(Android端的顶层control)
- model层的entity负责数据的获取、存储、数据状态变化;
- model层的event负责消息传递的基类,依赖EventBus;
- view层的activity最为顶层容器,往下是fragment,(provider为每个业务场景提供页面支持),配合model层的entity,解耦数据层和业务层;
- control层负责app内的网络请求,图片缓存,json解析,适配器数据绑定,file下载等;
这种mvc的设计,嵌套了mvp的设计思想,对整个model层进行了更细碎的划分,把更多业务逻辑分割在了model层,相应的减轻了view层逻辑的代码量,同时xml布局不再以场景来区分,仅以使用的组件类型来划分,provider与entity配合使用,fragment最为最终类;
Model
- base data(Property)
- url response(Response)
- sql manager(Database)