1、什么是架构模式？
刚作了软考题，有一道关于提问设计模式是什么的，设计模式是一套解决相似问题的经验的总结。采用设计模式的目的是为了可重用代码。而架构模式也一个通用的、可重用的解决方案。我以为他们的区别是，设计模式跟代码更有直接关系，html
架构模式站在系统全局的角度解决子系统之间的关系、功能需求与非功能的优先级与取舍原则等。java
2、分层模式
（参考https://www.cnblogs.com/IcanFixIt/p/7518146.html）mysql
这种模式也称为多层体系架构模式。它能够用来构造能够分解为子任务组的程序，每一个子任务都处于一个特定的抽象级别。每一个层都为下一个提供更高层次服务。分层模式的关键点在于肯定依赖：即经过分层，能够限制子系统间的依赖关系，web
使系统以更松散的方式耦合，从而更易于维护。区分层次的目的是为了“高内聚低耦合”的思想。在软件体系架构设计中，分层式结构是最多见，也是最重要的一种结构。常见的分层模式结构有如下几种：spring
一）通常信息系统中最多见的是以下所列的4层：表示层，业务逻辑层，持久层，应用层。
模式介绍：
- 表示层(也称为UI层)：主要对用户的请求接受，以及数据的返回，为客户端提供应用程序的访问。
- 应用层(也称为服务层)：服务层的做用就是将表现层与业务逻辑层之间完成解耦。那么表现层中就不会出现任何的业务代码，固然这样带来的好处也是显而易见的，就是当咱们修改业务层代码时，咱们不须要修改表现层的代码，
固然若是服务层设计的很差，那么可能会形成反效果。sql
- 业务逻辑层(也称为领域层)：主要是针对具体的问题的操做，也能够理解成对数据层的操做，对数据业务逻辑处理，若是说数据层是积木，那逻辑层就是对这些积木的搭建。无疑是系统架构中体现核心价值的部分。它的关注点
主要集中在业务规则的制定、业务流程的实现等与业务需求有关的系统设计，也便是说它是与系统所应对的领域逻辑有关数据库
- 数据访问层(也称为持久化层)：主要是针对非原始数据（数据库或者文本文件等存放数据的形式）的操做层，而不是指原始数据，也就是说，是对数据库的操做，而不是数据，具体为业务逻辑层或表示层提供数据服务。
案例分析---SSH的分层：
一、在表示层中，首先经过JSP页面展现信息设计模式
二、在服务交互层中实现交互，负责传送请求(Request)和接收响应(Response)，而后Struts根据配置文件(struts-config.xml)将ActionServlet接收到的Request委派给相应的Action处理，而后action进行对请求处理并转发给JSP页面。数组
三、在业务逻辑层中，管理服务组件的Spring IoC容器负责向Struts2提供具体的Action对象，提供业务模型(Model)组件和该组件的协做对象数据处理(DAO)组件完成业务逻辑，并提供事务处理、缓冲池等容器组件以提高系统性能和保证数据的完整性。架构
四、在数据访问层中，则依赖于Hibernate的对象化映射和数据库交互，处理DAO组件请求的数据，并返回处理结果，给业务逻辑层。
以***重大技术需求为例
若是需求征集页面接到了一个添加需求的请求，用户填完表单并提交，在web.xml配置了Struts2的拦截器，拦截表单提交请求，服务交互层根据Struts2的配置文件去服务交互层层的DemandAction,寻找保存的方法，该方法调用业务逻辑层
的方法demandService.Save(),业务逻辑层的这个方法又继续调用数据持久层的方法把数据保存到数据库，调用完毕以后返回save，服务交互层根据返回的结果save由服务交互层调用业务层的显示需求列表方法，业务层调用数据持久层数
数据库读取需求信息，回到表现层显示需求列表界面。Spring提供的IoC容器，咱们能够将对象之间的依赖关系交由Spring进行控制管理服务组件的Spring IoC容器负责向Struts2提供具体的Action对象，提供业务模型(Model)组件和该组件的
协做对象数据处理(DAO)组件完成业务逻辑。
二）微软推荐的分层式结构通常分为三层，从下至上分别为：数据访问层、业务逻辑层（又或称为领域层）、表示层。
- 表现层（UI）：通俗讲就是展示给用户的界面，用于显示数据和接收用户输入的数据，为用户提供一种交互式操做的界面。
- 业务逻辑层（BLL）：针对具体问题的操做，也能够说是对数据层的操做，对数据业务逻辑处理。对于数据访问层而言，它是调用者；对于表示层而言，它倒是被调用者。也将业务逻辑层称为领域层。
- 数据访问层（DAL）：该层所作事务直接操做数据库，针对数据的增、删、改、查。若是要加入ORM的元素，那么就会包括对象和数据表之间的mapping，以及对象实体的持久化。也称为是持久层。数据访问层中包含实体层（Model 实体层）
JavaWeb中典型的三层架构是：Jsp+Struts/spring+Hibernate的开发模式
简单工厂模式与三层架构：
三层在简单工厂的思想和基础上，为了达到更好的可复用性，可扩展性，可维护性和灵活性，把简单工厂的逻辑层进一步的分解，把逻辑层分解为逻辑判断层和数据访问层，让她们彼此直接的耦合度达到最低。不论是简单工厂仍是三层架构，它们
之间的最终目的是解耦，最终的效果是达到“高内聚，低耦合”的效果。三层架构咱们并不陌生，它是来源于简单工厂，可是高于简单工厂，它把简单工厂的粒度更加细化了，可是它们最终的目的是达到解耦。
一个餐馆的例子，若是从买菜上菜到作菜都是一我的，那我的生病了这个餐馆就不能营业了。若是有三我的分别负责招待客人、买菜、作菜，他们三我的有一我的生病的话，另外两个作简单的调整是能够营业的。也就是一层发生修改不会影响另外两层的
工做。招待客人的至关于表示层，只负责招待客人，作菜的至关于业务逻辑层按照表示层给的参数作菜，买菜的至关于数据访问层，只负责按照厨师给的单子买菜。
三）展现层，业务层，持久层，和数据库层。
如表1-1，有时候，业务层和持久层会合并成单独的一个业务层，尤为是持久层的逻辑绑定在业务层的组件当中。所以，有一些小的应用可能只有3层，一些有着更复杂的业务的大应用可能有5层或者更多的分层。与第一个四层不一样的是，展现层负责处
理全部的界面展现以及交互逻辑，业务层负责处理请求对应的业务，持久层负责对数据的操做，数据层负责操做数据库。
案例分析：
（参考https://blog.csdn.net/bboyfeiyu/article/details/45136299#t1）
为了演示分层架构是如何工做的，想象一个场景，如表1-4，用户发出了一个请求要得到客户的信息。黑色的箭头是从数据库中得到用户数据的请求流，红色箭头显示用户数据的返回流的方向。在这个例子中，用户信息由客户数据和订单数组组成(客户下的订单)。
用户界面只管接受请求以及显示客户信息。它无论怎么获得数据的，或者说获得这些数据要用到哪些数据表。若是用户界面接到了一个查询客户信息的请求，它就会转发这个请求给用户委托(Customer Delegate)模块。这个模块能找到业务层里对应的模块处理
对应数据(约束关系)。业务层里的customer object聚合了业务请求须要的全部信息(在这个例子里获取客户信息)。这个模块调用持久层中的 customer dao 来获得客户信息，调用order dao来获得订单信息。这些模块会执行SQL语句，而后返回相应的数据给业务层。当 customer object收到数据之后，它就会聚合这些数据而后传递给 customer delegate,而后传递这些数据到customer screen 展现在用户面前。
三 分层模式的特色
使用场景：
- 通常的桌面应用程序
- 电子商务Web应用程
模式特色：
- 每一个模块必须属于某个层次，为上层提供服务；同时委派任务给下层模块。
- 任何一个模块，都不能逆层次调用；属于下层的模块，不得调用（耦合）上层或上层次的模块。任何一个模块，都不得跨层次调用。
设计模式实现：
门面模式 ——咱们对于每一个模块或者每一个层次都会设计一个“门面”来下降耦合的复杂程度。
策略模式——抽象层次会隐藏底层的实现细节，这就是策略模式最基本的设计，咱们每每会把上层做为功能接口，下层做为可选的策略来实现。
优势
一、开发人员能够只关注整个结构中的其中某一层；
二、能够很容易的用新的实现来替换原有层次的实现；
三、能够下降层与层之间的依赖；
四、有利于标准化；
五、利于各层逻辑的复用。
六、结构更加的明确
七、在后期维护的时候，极大地下降了维护成本和维护时间
缺点
一、下降了系统的性能。这是不言而喻的。若是不采用分层式结构，不少业务能够直接造访数据库，以此获取相应的数据，现在却必须经过中间层来完成。
二、有时会致使级联的修改。这种修改尤为体如今自上而下的方向。若是在表示层中须要增长一个功能，为保证其设计符合分层式结构，可能须要在相应的业务逻辑层和数据访问层中都增长相应的代码。
三、增长了开发成本。