基于MVC的矩阵架构

为什么80%的码农都做不了架构师？>>>   

MVC

     Model View Controller，是模型(model)，视图(view)和控制(controller)的缩写。

     一种软件设计典范，用于组织代码用一种业务逻辑和数据显示分离的方法。

     MVC是一种框架模式，可以用代码来表示。

MVC几乎存在于各种计算语言的软件开发中，C、Java, JS, objective-C等等，可以说是放置四海皆准的一种框架模式。这种通用性很大程度上是取决于它是一种框架模式，它关注的是软件实现模式，不关注实现的目标，也不关注用什么来实现。就像我们吃饭一样，永远是用手将食物送到嘴里，并不关注吃的是什么。

由于MVC的这种特性使得它存在于各种编成语言中，它给软件的开发起到了显著的效果：

- 由于将显示于数据业务分离，可以让开发人员分别专著与显示或数据业务，更利于团队的开发

- 当前软件往往不是用一种语言完成，如数据业务用C，而显示用js，在这种情况下MVC将显示于数据业务的分离正迎合了这种情况。将开发人员在技术领域上可以清晰地划分开来。

- 显示于数据业务的分离也减少了前台与后台的耦合性，更加有利于软件在不同平台上的移植

- 显示于数据业务的分离有效提高了模块的重新性

- 开发人员技术领域的分离可以让开发人员更加专注于自己擅长的领域，给项目的进展起到很大作用

MVC在软件实现上确实起到很不可磨灭的作用，但以上的所有作用均强调软件的实现，这也是由MVC框架的出发点决定的，决定了无法关注用户需求，无法关注软件管理，无法关注软件维护。

MVC关注的是软件的实现，但在应付用户需求方面表现的比较弱。MVC无法告诉用户各个需求点在什么时候能完成，在客户需求增量开发上没能有体现。

MVC的团队由于是按技术领域进行组建的，因此在管理上很难从用户的需求上进行管理。这种模式下其管理往往由各个子团队领头人完成。

MVC是以软件层次进行组建的，因此在文件的部署上往往也是以软件层次来完成，如：显示层，业务逻辑层，则对后期以功能进行升级和维护带来一定的困难。

针对以上不足提出基于MVC的矩阵架构，如下图：

 

横向是以MVC的软件框架，纵向是以用户需求的功能点。

横向侧重软件的实现，纵向侧重用户需求。

横向关注软件设计、实现、部署以及开发人员的组建和技术结构

纵向关注需求分析、设计、实现以及功能的交付与管理

这种架构可以有效地弥补MVC在用户需求、软件管理以及维护上的不足。同时也能够再次提高软件的移植性（能很好的实现以功能点为单元的软件移植）以及重用性。

同时使软件后期维护变得更加简便。

基于以上框架对接下来的xcode上的一个软件在文件部署上进行了以下定义：

项目中新增以下文件夹：

Module: 存放功能模块代码文件，以M开头 M+功能名

Control:存放业务控制代码文件，以C开头  C+功能名

storyboard每个页面的名称为：功能名

这样遵循了MVC现有的文件部署，同时也很容易以功能为单元进行代码文件的提取。这种定义也许会出现部分冗余代码，但与将来的维护更新相比这不算什么。

每一个Controller创建一个子线程，完成一些需要时间比较长的后台数据处理，同时辅助主UI线程完成界面更形(大部分面向对象编程主UI线程完成界面加载后都无法对UI再进行更新，需要使用子线程来辅助完成)。

最后一句话是：框架只是给我们的实践提供理论上的指导，不应该框住我们的实践。

转载于:https://my.oschina.net/3wcar/blog/105676