关于框架的一些胡思乱想

题记：

最近这段时间一直混迹于一帮大神同学身边确实是学到了许多的东西，当然代价就是被打击的体无完肤，不过这也是值得的。今天中午和某神一起去吃中饭的时候聊了一路的android，讲了一些之前公司来学校招聘实习生的时候被问到的一些问题，然后就扯到的代码框架的问题上。在一旁聆听教诲了半天，自己也确实是发现在平时写代码的时候完全没有框架设计这个概念同时也是会感觉到做了许多的重复性工作而且程序的结构也是相当的混乱。于是乎开始摸爬滚打与各种博客论坛之间了。

1.MVC框架

首先自己以前是没有做过类似与网站的项目的，虽然说MVC平时听得也是很多但是具体是个什么东西确实也是一点都不清楚。在网上摸爬滚打了一阵之后大概得到这样的一个关于MVC的认识：

M：model

在三层结构中，model层次主要的职责是处理程序的业务逻辑。老实说自己现在对于业务逻辑的理解也是基于一定的形象上的描述，就是对于我们程序中的各种数据的一些功能性处理。

V:view

view层次的作用就是比较明显的——与用户进行交互，获取用户的操作。在android项目中或者可以类比到我们写的XML布局文件。

C:control

control层次负责的程序逻辑。与之前的model业务逻辑相比较，control的作用就相当是我们的程序的中枢调度系统，同时control也负责获取程序的输入。

三个层次的大致关系：

从上面的说法来看，MVC之间的大致关系应该是可以这样子理解：

view作为与用户进行交互的UI界面自然而然也就具有了提供用户进行输入的功能（输入接口），而control的职责中有意向就是负责管理输入，之后就是调度相应的model对输入进行处理，之后再是显示到view表现给用户。

而我们现在在开发android项目的时候也可以借鉴MVC这样一个框架来设计我们的应用程序使得我们的程序变得更加的明朗和简介。虽然MVC最初的目的并不是为了Android而设计，但是我们仍然可以看到一些转换的余地：

我们可以将android中的xml布局文件看作是view层，负责与用户进行交互同时提供了输入输出的接口。

之后可以再activity中部署我们的control层次来控制程序逻辑选择正确的view和model进行跳转

最终，我们要将负责业务逻辑的model解耦出来成为一个部分。

这样，整个android项目多多少少变得更加清晰明朗同时也提高了代码的重用性减少了模块之间的耦合性。

（未完待续。。。）