一个App架构例子分析--使用MVP模式;使用Otto实现模块通信

一、这个App整体的架构划分:

分为四大模块:

1.app模块

2.common模块

3.domain模块

4.model模块

app模块的依赖:

dependencies {
    compile fileTree(dir: ‘libs‘, include: [‘*.jar‘])
    compile project(‘:domain‘)

...

}

它依赖domain,领域层模块。在app模块中,应用了MVP模式,把一个activity中的View和Presenter划分掉。

domain模块的依赖:

dependencies {
    compile project (‘:common‘)
    compile project (‘:model‘)

...

}

它依赖model模块。领域逻辑代码放在这个模块;需要获取数据,获取数据的实现代码则放在module模块;它依赖common,通用的功能,整个应用共用的代码,放在common模块中。

model模块的依赖:

dependencies {
    compile project(‘:common‘)

....

}

这个模块只依赖common模块。model模块提供数据获取,修改功能。

common模块的依赖:

dependencies {
    compile ‘com.squareup:otto:1.3.5‘
    compile ‘com.google.dagger:dagger:2.0‘
    compile ‘org.glassfish:javax.annotation:10.0-b28‘
}

它不依赖domain,app,model模块。它使用第三方类库,来给其它模块提供功能。使用Dagger依赖注入框架,进行依赖注入;使用otto类库,来实现总线方式的通信。

二、整个执行流程简要分析

app模块:

MoviesActivity,MoviesPresenter。

domain模块:

ConfigurationUsecase, GetMoviesUsecaseController。

module模块:

RestMovieSource。

模块之间的通信,协作使用Bus总线来实现。比如,module模块,接受了数据查询的请求,查询完毕之后,它就通过总线post出去;然后,app模块或者domain模块,使用总线订阅了某个事件,那么订阅该事件的方法就会被回调。

三、依赖注入框架,注入流程

时间: 2024-11-05 13:48:40

一个App架构例子分析--使用MVP模式;使用Otto实现模块通信的相关文章

Android架构篇--MVP模式的介绍篇

摘要: 在MVVM成熟之前MVP模式在Android上有被神化的趋势,笔者曾经在商业项目中从零开始大规模采用过MVP模式对项目进行开发.在使用MVP模式进行开发的时候发现项目的结构模式对开发是有一定的影响的,在这里笔者会对这一问题进行探讨.希望通过这篇blog能让读者了解如何使用MVP模式搭建一个功能完善的MVP模式开发框架,避免一些笔者认为比较严重的问题. 为什么要使用MVP模式 在传统的Android开发中,我们一般是使用MVC模式进行开发的.传统MVC模式介绍: View: 视图层,对应x

关于Android MVP模式的思考

最近经常看到各种介绍MVP模式的博客的,之前写过不少的Android应用,在做那些应用的时候,都是要求快速完成,所以从开始设计到写代码就一直考虑着重用.以前写的项目基本都是不断重构项目,将项目代码变得更加精简,提高代码之间的复用性.但是代码并没有特别地注重按照MVC模式或者是MVP模式来,更多的是直接考虑模块化,重用,精简.所以看了MVP模式后,决定去总结一下自己代码中的问题并优化,算是对自己之前写的代码的回顾. MVP框架 MVP框架是目前在Android流行起来的框架,它非常适合用于Andr

Hybrid APP架构设计思路

原文:Hybrid APP架构设计思路 关于Hybrid模式开发app的好处,网络上已有很多文章阐述了,这里不展开. 本文将从以下几个方面阐述Hybrid app架构设计的一些经验和思考. 通讯 作为一种跨语言开发模式,通讯层是Hybrid架构首先应该考虑和设计的,往后所有的逻辑都是基于通讯层展开. Native(以Android为例)和H5通讯,基本原理: Android调用H5:通过webview类的loadUrl方法可以直接执行js代码,类似浏览器地址栏输入一段js一样的效果 webvie

浅谈Android中的MVC与MVP模式

使用MVC或者MVP模式会增加很多的类,但是确可以让代码结构变得清晰,方便了后期维护拓展方便.把数据层跟视图层分离,处理事务的逻辑单独的放在一个类中,让Activity仅仅具有展示功能. 下面我们就MVC模式跟MVP模式进行分别讲解,总之来说各有利弊.在实际的开发中,我们根据实际情况进行取舍.个人认为MVP模式更简单一些,因为MVP模式中会把部分逻辑Activity中,但是这就造成了Activity的相对繁琐,没有实现完全的隔离.而我们采用的MVC模式则是更好的处理了这个问题,但是在应用的过程中

app架构学习之MVP

App有一个好的架构,它可以带来如下的好处:容易扩展:容易维护.如果一个App没有一个好的架构,那么,耦合的代码会到处出现.没有一个架构,那么,代码会是各种混乱,我深有体会. 混乱,看起来问题不大,对于小规模的app,因为,我始终还是可以花时间读懂它.但是,随着app的功能越来越多,那么,你每次添加一个功能或者修改一个功能的时候,你会发现:1.你做的功能和之前做的功能,有重复代码.2.你难以快速完好,正确的修改一个功能,因为代码过于耦合,因为代码层次不清楚. 总之,过去的经验告诉我,要对一个Ap

Android 架构设计实现——MVP模式

转载请注明出处:http://blog.csdn.net/smartbetter/article/details/70853135 随着 UI 创建技术的功能日益增强,UI 层也履行着越来越多的职责.为了更好地细分视图(View)与模型(Model)的功能,让 View 专注于处理数据的可视化以及与用户的交互,同时让 Model 只关系数据的处理,基于 MVC(Model View Controller) 模式的 MVP(Model-View-Presenter) 模式应运而生.目前MVP模式在

移动APP架构模式

移动APP架构模式 本文主要总结了几种常用的架构模式, 基本是层层递进的, 转载请注名出处: http://blog.csdn.net/uxyheaven 在一个app的不同生命周期采用不同的架构模式可以有效的提高开发效率 基本的MVC 移动app一般都是采用经典的mvc架构 层次 作用 设计原则 模型层(model) 封装了应用的一系列数据, 并定义了操作, 处理这些数据的逻辑和计算规则. 通过C:Notification,KVO对控制器进行反馈 视图层(view) 视图对象是一个应用中, 用

一个可以实时跟踪分析iOS App视图的小工具

一个可以实时跟踪分析iOS App视图的小工具(已开源) GitHub入口:https://github.com/sx1989827/RunTrace 前言 作为iOS的开发者,常常为了UI界面搞得头破血流,你是不是经常遇到这样的痛点:这个view是从哪里来的,它的父视图是什么,它的子视图有哪些,它的frame会发生什么样的变化,它怎么突然隐藏了,它什么时候会被释放掉,对于像自动布局,错误常常如潮水般的涌来,我想动态获取一个view的约束怎么办,我想知道这个view此时此刻和其他哪些view产生

Android MVP模式简单介绍:以一个登陆流程为例

老的项目用的MVC的模式,最近完成了全部重构成MVP模式的工作,虽然比较麻烦,好处是代码逻辑更加清楚.简洁,流程更加清晰,对于后续版本迭代维护都挺方便.对于一些想要学习MVP模式的同学来讲,百度搜出来的好多都没法直接转化为项目里可以直接用的东西,所以这里正好拿出自己项目里已经用了的,你们可以直接用到自己的项目里.当然,不可能把所有项目代码在这里放出来,所以就拿登陆的流程出来,这个比较合适也比较常用. 1.先看下包结构: model:放一些bean类,以及网络处理类RetrofitManager,