很多人表示对架构一窍不通，想了解架构，但是看了网上的一些文章，感觉云里雾里。事实上，建筑远没有那么难。从今天这篇文章开始，我就给大家讲讲结构，尽量让大家看得懂。1.什么是架构？对于架构，业界一直没有一个统一的定义。建筑一词最初来自建筑业。如果我们要建造一座建筑物，那么在完成这样一个重大项目之前，我们必须需要建筑师的建筑图纸。而这张建筑图可以说是建筑业结构的核心体现。它描述了建筑物的外观、内部结构、公寓设计、材料方法、设备、结构等。有了建筑图，就可以统筹规划整个项目。从大局出发，有序推进项目建设，最大限度地提高生产力。所以归根结底，架构的目的是为了提高生产力。软件领域的架构主要体现在模块之间的“高内聚低耦合”。这六个字听起来有点难懂。其实一般情况下，单一职责的功能都是封装成模块的，模块内部是高度聚合的。模块之间互不依赖，即低耦合。比如我们常用的网络库和图片加载库就属于两个模块。每个模块都有单一的内部功能和高度内聚的代码。但是网络库和图片加载库不依赖，可以独立工作。没有干扰，这就是所谓的低耦合。我们追求“高内聚、低耦合”的目的很简单。我们希望开发人员只关注一点。在提高开发效率的同时，对代码的健壮性和可扩展性也有很大的好处。试想一下，如果你做的功能需要同时跟四个部门合作，依赖他们的模块，那你的开发效率肯定是极低的，而且依赖度太高，稍微改动一下其他的代码部门很可能会影响你。影响，且问题不易定位，将是一颗定时炸弹。因此，架构的重要性不言而喻，但架构有一个原则：不要过度设计！如果你是盖楼房，肯定会需要建筑师的建筑图纸，但如果你是盖茅草屋，你觉得还需要请建筑商给你设计好建筑图纸再开始施工吗？也许设计建筑图纸所花费的时间足以让您完成建造。因此，架构必须取决于不同场景的需求。如果你的项目一共有十个文件，那么你在开发过程中使用各种设计模式，考虑各种层次，只会把原本简单的事情复杂化。也会增加工作量，违背了架构的初衷。最原始、最简单的东西是最高效的，但是我们的项目逐渐变得庞大，最原始的框架和结构已经不能满足我们的需求了。这个时候，我们就必须从全局的角度重新考虑整个项目。架构，通过架构帮助我们提高生产力，减少重复复杂的工作量，提高工作效率。2.三层架构说到架构，就不得不说到三层架构这个最经典的概念。三层架构最初是由微软提出的，建议所有的应用程序都应该遵循这种分层的方式。今天，大多数应用程序基本上都遵循这种三层分层架构。三层架构为：表现层、业务层、数据访问层。让我们以访问一个网站为例。当你在浏览器中输入一个网址，访问一个网站的时候，中间有这么一个过程。用户在浏览器中输入网址，然后浏览器向服务器发起http请求。条件去数据库查询相关数据，然后将数据以特定格式返回给浏览器（网站是html格式），浏览器根据特定数据渲染相应的页面。这对应于三层架构。首先，对于用户来说，浏览器就是表现层。主要是一个与用户交互的页面，根据用户的输入和事件，对返回的具体数据进行处理和展示。我们知道数据是所有应用程序的基础。如果没有数据，那么就没有意义。因此，服务器必须有一个强大的数据库来存储用户交互产生的所有数据，而对这些数据的处理包括增删改查，属于数据访问层。那么，连接表现层和数据访问层的就是业务逻辑层，包括模型设计、验证、业务规则，以及后台程序中的各种计算。因此，后端架构非常复杂。除了复杂的业务逻辑，它还有存储、性能、并发、负载均衡等，所以架构师这个职位本来就是服务端的职位。3、随着移动终端的普及，MVC的移动应用程序功能越来越多，项目也越来越复杂。因此，越来越多的人关注和重视移动端架构，但移动端架构远不及服务器端。这很复杂。首先，移动端的数据来自服务器。不需要专门的数据存储。顶多有本地缓存??和一些必要的小数据库。对于一些复杂的业务逻辑，更多的是放在服务端，客户端不需要考虑百万级用户同时访问，移动端通常应该以UI、交互、体验为主，所以客户端的架构不是这样的重，但是为了让移动端代码层次更清晰，代码扩展性更好，更好的高内聚低耦合，目前有一系列的移动端架构方案，比如MVC、MVP、MVVM、Clean等，这是每个人都熟悉的。今天，我们来谈谈Android开发中MVC的概念。MVC是Model（模型）、View（视图）、Controller（控制器）的缩写。View层处理界面显示，Controller层用于处理用户交互和事件，Model层用于定义实体对象和处理业务逻辑。.说起来难免有些晦涩，下面以我们最熟悉的Android开发为例。4、AndroidMVC其实Android开发本身就默认了一套MVC的实现。View层：Android开发中的xml布局就是我们的View层。默认情况下，建议所有View尽量用xml实现。当然，对于一些复杂的，我们需要自定义View。自定义View也属于View层。但大多数时候，xml布局用得最多；Controller层：毫无疑问，Android默认也为我们提供了Controller，也就是Activity&Fragment。仔细想想，是不是用户交互事件，比如输入、点击、滑动等，都是在Activity和Fragment中处理的？关于这一点，有人认为Activity&Fragment属于View层。我不同意这一点。View应该专注于界面的展示，Controller处理用户的交互，提供View需要的数据。让View正确显示，这就是Activity&Fragment的工作。Model层：View和Controller在Android中定义。其实Model层是没有定义的，大部分架构都没有定义Model层，因为Model本身是和业务相关的。针对不同的业务模型，定义需要数据模型和实体类，以及相关的业务逻辑处理，虽然Android没有明确定义Model层，但是我们在开发中会定义一个专门的模型包来管理所有的模型文件，比如作为用户、订单、聊天等。这里补充一下，因为有些初学者可能不明白什么是Model，Model的具体职责，所谓的业务逻辑是什么？这里解释一下：1.Model是模型，也就是数据模型，通常就是所谓的JavaBeanEntity类，比如我们要在界面上显示一些用户信息。这时候，我们必须定义一个User对象。这个User对象也就是所谓的Model，比如publicclassUser{privateintage;privateStringname;private...publicvoidsetAge(intage){}publicintgetAge(){returnage;}...}通常这是Model的主要功能。2.Model是数据模型的定义，它定义了我们使用的数据实体类。因为我们的数据源大部分来自后端，客户端不需要处理太多的业务逻辑，所以大多数情况下Model只包含基本属性和get、set方法。但是，这并不意味着客户端不包含任何业务逻辑。比如，除了展示用户的基本信息，我们还需要展示用户的体重指数（即BMI）。这个值并不是Model自带的属性，而是根据一些属性通过一定的算法计算出来的，也就是所谓的业务逻辑。BMI的算法很简单，就是体重(kg)÷(身高^2(m))，有人可能直接把这个算法写在显示的页面上，比如直接在Activity中有如下代码：textView.setText(String.valueOf(user.weight/(user.height*user.height)));这当然可以，但是很可怕，因为你需要在每一个展示的地方都写这么一段代码，属于业务逻辑。所以你应该把这个算法放在用户模型中：publicclassUser{privateintage;privateStringname;privatefloatweight;privatefloaheight;......publicfloatgetBMI(){returnweight/height*height;}}并且只需要显示在需要的地方调用user.getBMI()是可以的。这个算法其实就是所谓的简单业务逻辑。当然，以上只是一个例子。其实这是一个很简单的概念，只是有些初学者可能不太理解。说明一下，在实际开发过程中，所有与模型相关的计算都可以算作业务逻辑，这也是模型。第二个重要作用。5、MVC和三层架构的关系有人会问，你后面讲三层架构和MVC，他们是什么关系？三层架构是软件领域最常见的分层体系。架构，而MVC是在三层架构的基础上设计的框架式架构。三层架构是一个宏观的概念，MVC是三层架构更具体的框架实现。在MVC的基础上，我们在上面对不同类型的代码文件进行分类就足够了，所以它们之间的关系可以用下图来表示：从上图可以看出，View层和Controller层都属于三层架构的表现层，而Model层属于业务层，又有人问了，为什么没有相应的数据访问层呢？这是一个有争议的点。有人认为，Model层除了定义业务需要的实体类和简单的逻辑算法处理外，还应该包括对数据库、网络等的操作，这对后端开发来说是没有问题的，因为所有的后端的数据来自于数据库，后端可以方便的连接到数据服务器，而Model的大部分业务逻辑都来自于对数据的处理，所以这种方式很正常。但是对于客户来说，区别就非常大了。我们知道客户端的大部分数据来源都是来自服务端的接口请求，但是很有可能同时有本地数据库和本地文件可以提供数据。比如可能有离线操作，比如为了用户体验，会在用户断网的时候进行缓存处理，这就意味着客户端有各种数据来源，主要负责的是模型本身应该是定义业务所需的数据模型和简单的逻辑处理。数据库和网络数据不可避免地变得臃肿，职责不明确。因此，我不建议在Model层做冗余的数据处理工作。对应三层架构，我强烈建议在客户端的开发中应该多一个数据层，也就是所谓的数据处理层。该层包括对数据库、网络、sharedpreference等数据的处理，Model层回归到最简单最本质的模型职责，只定义业务需要的数据模型和简单的逻辑处理。6、MVC的优缺点虽然Android开发框架不是严格意义上的MVC，但是很明显默认开发的是MVC框架。优点也很明显，学习成本很低，简单易懂。分离，我们只需要对Model层和数据层做一个简单的分层和封装，就是一个相当可扩展和相当清晰的开发架构。但缺点也很明显。随着功能的不断迭代，交互处理越来越复杂，Controller层，也就是Activity和Fragment中的代码越来越臃肿，难以维护，尤其是在需求变化的时候，改起来很痛苦。我什至见过一个Activity有几千行代码。想象一下这是多么痛苦。当然这种情况本身就有程序员自身的问题，但是暴露了MVC架构的不足。MVC可以说是最经典的架构模式，适用于绝大多数的开发场景。如果你对架构不是很了解，那么还是建议老老实实的使用MVC。基于这个架构封装和优化肯定是够了，但是项目已经到了一定的规模，需求也越来越复杂。到最后会难以扩展，Controller层会发展成“死胖子”。这个时候怎么解决呢？且听下一章。我也不确定。【本文为专栏作者“stormzhang”原创稿件，转载请联系原作者（微信ID：googdev）】
