MVPC架构项目

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(实体类)
• 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)

1. model层的entity负责数据的获取、存储、数据状态变化；
2. model层的event负责消息传递的基类，依赖EventBus；
3. view层的activity最为顶层容器，往下是fragment，（provider为每个业务场景提供页面支持），配合model层的entity，解耦数据层和业务层；
4. control层负责app内的网络请求，图片缓存，json解析，适配器数据绑定，file下载等；

这种mvc的设计，嵌套了mvp的设计思想，对整个model层进行了更细碎的划分，把更多业务逻辑分割在了model层，相应的减轻了view层逻辑的代码量，同时xml布局不再以场景来区分，仅以使用的组件类型来划分，provider与entity配合使用，fragment最为最终类；

---

Model

• base data(Property)
• url response(Response)
• sql manager(Database)