Android 开发 代码结构规范 MVC模式

MVC (Model-View-Controller)：M是指逻辑模型，V是指视图模型，C则是控制器。一个逻辑模型可以对于多种视图模型

使用MVC的目的是将M和V的实现代码分离，方便扩展，便于以后的管理

从开发者的角度，MVC把应用程序的逻辑层与界面是完全分开的，最大的好处是：界面设计人员可以直接参与到界面开发，程序员就可以把精力放在逻辑层上。

Android中也可以说采用了当前比较流行的MVC框架，在Android中：

1) 视图层（View）：一般采用XML文件进行界面的描述，使用的时候可以非常方便的引入，但是用xml编写了，又需要在Acitvity声明并且实例化，有点麻烦，考虑能否做一个类似注解实现匹配，或者写一个类获取xml的各个节点然后自动进行封装，当然，这只是个想法，以后再实现。

　　2) 控制层（Controller）：Android的控制层的重任通常落在了众多的Acitvity的肩上，要通过Activity交割Model业务逻辑层处理，这样做的另外一个原因是Android中的Acitivity的响应时间是5s，如果耗时的操作放在这里，程序就很容易被回收掉。

　　3) 模型层（Model）：对数据库的操作、对网络等的操作都应该在Model里面处理，当然对业务计算等操作也是必须放在的该层的。

这是我的目录结构：



代码讲解：

模型层（Model）： 分了model包和dao包，

model包主要是对对象的封装和一些简单的对象逻辑

dao包主要是对数据库的操作和对网络的操作

MODEL：

DAO：

视图层（View）：

对安卓来说，就是XML的布局文件。用代码实现android布局不明智

控制层（Controller）：

activity包，Android的控制层的重任通常落在了众多的Acitvity的肩上，要通过Activity交割Model业务逻辑层处理。但是所有的控制层逻辑都写在activity又感觉太臃肿了，一个activity几百行代码，维护起来也不方便，所以就分了一个ctrler的包。

ctrler包：activity包主要实现与视图层的逻辑处理，ctrler包更多用于实现与model层的业务逻辑处理。

adapter：不用多说，android自己实现的数据和UI（View）之间一个重要的纽带，[b]直观的表达了Data、Adapter、View三者的关系。[/b]

activity: (主要实现从服务器做登陆，并且获取通知初始化listview)

三步走 (不同布局都一样，三步走)：

一、initView（）；初始xml的视图布局

二、getData（）； 获取数据

三、initAdapter（）； 初始数据

ctrler： （负责业务逻辑，通过此类获取数据并返回给activity处理视图逻辑）

config是项目的一些常用数据的配置

util是放工具类的

主要是一开始经常会把所有逻辑直接写在activity里，导致activity很臃肿，维护不方便，导致activity里代码过于集中，所以强行把项目结构改成这样。