javaee-应用程序组件-分层模型与分层架构

1 最典型的四层结构：客户层，Web层，业务层，EIS层

这里，没有画出持久化的那一层，但可以看到，最明显的Web层和业务层，而JavaBean在每一层中都可以用于数据封装。

如果把持久化层加入进来，应该就是这样

2 另外的参考

不管是经典的JAVAEE架构，还是轻量级JavaEE架构，大致上都可以分为如下几层：

1、Domain Object（领域对象）层：此层由一系列的POJO（Plain Old Java Object）组成，这些对象是该系统的Domain Object,往往包含了各自所需实现的业务逻辑方法。

2、DAO（Data Access Object,数据访问对象）层：此层由一系列的DAO组件组成，这些DAO实现了对数据库的创建、查询、更新和删除（CRUD（增加(Create)、读取(Retrieve)(重新得到数据)、更新(Update)和删除(Delete)））等原子操作。{在经典JAVAEE应用中，DAO层也被改称为EAO层，EAO层组件的作用与DAO层组件的作用基本类似。只是EAO层主要完成对实体（Entity）的CRUD操作，因此简称EAO层。}

3、业务逻辑层：此层由一系列的业务逻辑对象组成，这些业务逻辑对象实现了系统所需要的业务逻辑方法。这些业务逻辑方法可能仅仅用于暴露Domain Object对象所实现的业务逻辑方法，也可能是依赖DAO组件实现的业务逻辑方法。

4、控制器层：次层由一系列控制器组成，这些控制器用于拦截用户请求，并调用业务逻辑组件的业务逻辑方法，处理用户请求，并根据处理结果转发到不同的表现层组件。

5、表现层：此层由一系列的JSP页面、Velocity页面、PDF文档视图组件组成，负责收集用户请求，并显示处理结果。

原文：https://blog.csdn.net/u013473691/article/details/50382496

3 对于后端的分层【当启用了Mybatis时，会有Mapper层取代了Dao】

分层：Controller - Service - Mapper - Manager
1、Service层之间不能互相调用，需要的操作可以上升到Controller层。
2、微服务之间的接口调用写在manager层

web离我们很近，我们用浏览器通过网络访问一个网站的步骤对于我们开发者而言就是一个web的开发过程，要阐述并理解清楚我们的web应用分层模型与组件才能切实理解。各层的javaEE组件之间以松耦合的方式耦合在一起，各组件并不以硬编码方式耦合，这种方式是为了应用以后的扩展性。 从上向下，上面组件的实现依赖于下面组件的功能；从下向上，下面组件支持上面组件的实现。

java web模型

                                   表现层       -》网站的页面显示，同时收集用户请求信息
                                        |
                                  mvc控制层   -》用于处理用户的请求（过滤型），以及将处理结果发给表现层
                                        |
                                  业务逻辑层    -》根据上获取的数据，调动业务处理逻辑处理
                                        |
                                  DAO 层（data access object） -》数据访问层，用于对数据库进行CRUD操作，c：create，r：reasearch，u：update，d：delete，
                                         |
                                   Domain Oject  -》领域对象层上述是一个封装，这一层是具体的对象对持久化层，也就是数据库进行访问
                                         |
                                      数据库

java web组件

表现层组件：jsp页面，或者智能前端，android，ios
控制器组件：前端的核心控制器，负责拦截用户请求，并处理
业务逻辑组件：系统的核心组件，实现系统的业务逻辑
DAO组件：数据访问的接口
Domain Object：数据库数据的记录方式

4 JDBC和JNDI

5 三层架构

三层架构自上而下将系统分为表示层、逻辑层、持久层。
表示层由处理用户交互的客户端组件及其容器所组成；
业务逻辑层由解决业务问题的组件组成；
数据层由一个或多个数据库组成，并可包含存储过程。
这种三层架构，在处理客户端的请求时，使客户端不用进行复杂的数据库处理；透明地为客户端执行许多工作，如查询数据库、执行业务规则和连接现有的应用程序；并且能够帮助开发人员创建适用于企业的大型分布式应用程序。

这应该是典型的Model2的造型了
很明显看到Controller在表现层了
而Service在模型层

6 基于JavaEE架构模式下的MVC

在这种架构模式下，模型层（Model）定义了数据模型和业务逻辑。为了将数据访问与业务逻辑分离，降低代码之间的耦合，提高业务精度，模型层又具体划分为了DAO层和业务层，DAO即Data Access Object，其主要职能是将访问数据库的代码封装起来，让这些代码不会在其它层出现或者暴露出来给其它层；业务层是整个系统最核心也是最具有价值的一层，该层封装应用程序的业务逻辑，处理数据，关注客户需求，在业务处理过程中会访问原始数据或产生新数据，DAO层提供的DAO类能很好地帮助业务层完成数据处理，业务层本身侧重于对客户需求的理解和业务规则的适应，总体说来，DAO层不处理业务逻辑，只为业务层提供辅助，完成获取原始数据或持久层数据等操作。

• JSP：JSP被用来产生Web的动态内容。这层把应用数据以网页的形式呈现给浏览器，然后数据按照在JSP中开发的预定的方式表示出来，这层也可以称之为布局层。
• Servlet：JSP建立在Servlet之上，Servlet是J2EE的重要组成部分。Servlet负责处理用户请求，Java
• Web项目的所有配置都写在了web.xml配置文件里，当项目运行的时候，web.xml会将http请求映射给对应的Servlet类。
• JavaBean：由一些具有私有属性的Java类组成，对外提供get和set方法。JavaBean负责数据，负责处理视图层和业务逻辑之间的通信。
• Service：业务处理类，对数据进行一些预处理。
• DAO：数据访问层，JDBC调用存储过程，从数据库（DataBase）那里获取到数据，再封装到Model实体类中去。

7 前端和后台

从大的范围来分，软件可以分为两个层次：前端和后台。
这两个概念大家应该都很熟悉。很多程序员招聘广告，都区分前端工程师和后台工程师。

前端
前端，也常称为UI。是用户界面应用程序。用户界面应用程序，是直接和用户进行交互的软件。
常见的前端应用有：命令行程序，Web应用，桌面应用（包括移动设备应用）。除了命令行程序外，都是图形化界面。本文只介绍图形化界面的前端程序。
前端程序，负责与用户进行交互。负责接收和校验用户输入，并向用户反馈输出。其业务操作是委托给后台来实现的。
前端程序，必用的设计模式，是20世纪80年代发现的MVC模式。所有成功的前端应用，都使用了MVC模式或者它的一些变体。

MVC模式，MVC全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写。它是Gof设计模式一书中介绍的第一种设计模式，是设计模式之母。
MVC模式，就是用控制器来管理用户输入、输出和图形界面。数据来自模型部分。模型Model实际上集中管理了业务数据。这使对同一种业务数据展现多种图形界面成为了可能。MVC模式，分离了显示逻辑和业务逻辑。
应用MVC模式的前端应用中，模型Model是通向后台系统的通道。

后台
前端应用负责提供与用户交互的软件。后台则向前端提供业务服务。所有业务相关的操作和服务应该由后台来实现。
前端和后台，可以是在同一个进程中的，也可以是分属不同进程的。
一般，较简单或者小型的单机系统，前端和后台都在同一个进程中。也就是都属于图形应用程序(或者命令行应用程序)。
这种应用程序，前端部分代码，通过API调用直接调用后台提供的业务服务。如Office软件就是单机系统。
复杂或者分布式系统，前端和后台属于不同的进程，前端通过进程间调用机制来调用后台提供的业务服务接口。
目前常用的进程间调用机制有：WebService、REST、基于TCP自己实现的通讯协议，编程语言自己定义的通讯协议，操作系统自己定义的通讯协议等。如，现在很多企业级应用软件，Web应用，互联网应用等。

后台系统本身，也需要分为多个层次，包括：接口层，业务层，助手层。分别对应于大家应该都很熟悉的JavaEE中的表现层，业务层，持久化层。
接口层
接口层，在JavaEE中称为表现层。就是后台系统对外的接口层，用于实现跨进程调用。接口层的代码，和你使用的进程间调用机制有关。
如，你使用WebService，那么接口层就是用来处理WebService请求的代码；你使用Rest，那么接口层就是处理Http请求和返回Http响应的相关代码；你使用的是RMI这样的语言定义的通讯协议，接口层就是用RMI协议接收和发送数据的相关代码。
接口层，应用了Gof设计模式中的Façade门面模式。它向前端（客户端）提供了一个简洁一致的接口，隐藏了系统的复杂性。只要保证接口不变，那么后台的业务层和助手层代码再怎样变化，对前端（客户端）程序都是透明的。
JavaEE中称之为表现层，意为和Web图形界面有关。这是因为当时JavaEE提出这种分层时，Struts等JavaWeb前端框架正大行其道。Struts等会把html页面返回给浏览器，具备呈现图形界面的功能。
但目前，前端和后台完全分离的应用很多，并已经成为一种趋势。如，前端是桌面应用或者移动应用，显然只需要和后台交换业务数据，不需要后台返回图形界面。Web开发中，目前也流行Html页面上嵌入JavaScript代码通过AJAX向后台交换业务数据，而不是要求后台返回html页面。接口层不再需要返回html页面，只需要返回数据。
因此这里我命名为接口层而不是表现层，更为贴切。
另外，对于前端和后台在一个进程中的软件，无需定义接口层。前端部分直接通过API调用后台部分的业务代码即可。

业务层
业务层，负责定义领域对象，完成业务逻辑的处理。它向前台提供后台需要的所有服务。
每一个应用程序，都有其需要解决的问题。针对其问题域，需要划定问题范围，进行数学建模，识别领域对象，并定义各个领域对象之间的关系。
数学建模和识别领域对象的方法有多种。
1，请需求方描述清楚问题是什么，想要得到什么结果。
2，描述自己的解决方案，能够做到什么，寻求需求方的确认。
3，对解决方案文字化。找出其中所有名词和动词。名词就是领域对象的候选对象。动词是领域对象的方法的候选对象。寻找名词之间的制约关系。
4，确定领域对象的关系。我使用关系数据库的设计方法，确定对象之间是一对一关系，多对一关系还是多对多关系。
关系数据库实际上和面向对象系统是完全等价的。这可以从很多O-R mapping框架上看出来。
5，根据识别出的领域对象，及其相互之间的关系，需要实现的方法，用面向对象的思维编码。用面向对象的思维编码，不意味着必须使用类。用C这样的过程式编程语言也可以用面向对象的思维编码。只是你心中要放着对象这个概念即可。如，我用Python编码时，很少使用类，经常是直接使用函数。但心中还是存着“对象”的理念的，这样写出的代码才不会乱。
助手层
业务层代码，会需要使用一些第三方软件提供的服务或者其他更低层级的自己开发的软件服务，才能实现其业务逻辑。
这些不属于接口层，也不属于业务层的代码，我们称其属于助手层。助手层代码是为了协助业务层代码实现功能而存在的。
助手层，在JavaEE中称为持久化层。
因为JavaEE是一个企业级软件架构设计方案。其针对的是企业的信息系统。其业务逻辑一般就是操作数据库。
数据库的读写访问，是与具体业务逻辑无关的，是帮助实现业务逻辑的。因此JavaEE称为持久化层。但这个定义也不全面。
因为还是存在很多系统，其除了访问数据库外，还需要其他服务才能实现业务逻辑。
因此，我认为称之为助手层比持久化层更具普适性。

因此，服务层和助手层的区别，实际上是逻辑概念上的区别。一个系统的服务层，对于其他系统可能就是助手层。
比如，一个企业信息化应用，需要处理一些时间、字符串、集合等相关的函数。这些函数在这个应用中就属于助手层。因为时间，字符串，集合都属于我的系统的领域对象，它们是为业务服务的。是更低一个层级的。
总之，后台部分中，不属于接口层和业务层的所有代码，都属于助手层。
业务层和助手层的区别

小结
分层的软件设计思想已经存在很多个年头了，在计算机科学的各个领域都证明了它的成功。
前端（MVC模式）和后端（接口层-业务层-助手层）的分层设计也经过了几十年大量软件的证明。
分层的思想，就是每一个层次专注做一件事情。每一个层次都为上层提供服务。每一个层次对于其上层来说，都是可以复用的。
分层设计的软件，结构清晰，代码各司其职，能够最大限度地重用代码。