请问JAVA三层架构，持久层，业务层，表现层，都该怎么理解和MVC三层模型有什么

Model:数据持久层，对数据库的数据进行处理，主要就是数据库 *** 作，常见的技术就是JDBC 、 hibernate 、 mybatis这些数据持久层 *** 作的技术和框架。

view:表现层，就是展示给用户看的那些网页和界面，常见的就是jsp和html 。

Controller:业务层， 就是在Model 和 view之间进行数据交换，Servlet是最基本的，其它的框架技术 常见的就是Struts 、 SpringMVC 什么的。

本人主要是学java的，主要了解的就这么多，分三层主要就是将各个功能区分开，方便开发……

OSI参考模型从低到高依次是：物理层、数据链路层、网络层、传输层、会话层、表示层和应用层。

OSI参考模型也采用了分层结构技术，把一个网络系统分成若干层，每一层都去实现不同的功能，每一层的功能都以协议形式正规描述，协议定义了某层同远方一个对等层通信所使用的一套规则和约定。每一层向相邻上层提供一套确定的服务，并且使用与之相邻的下层所提供的服务。

从概念上来讲，每一层都与一个远方对等层通信，但实际上该层所产生的协议信息单元是借助于相邻下层所提供的服务传送的。因此，对等层之间的通信称为虚拟通信。

扩展资料：

运作方式

数据由传送端的最上层(通常是指应用程序)产生，由上层往下层传送。每经过一层，都在前端增加一些该层专用的信息，这些信息称为报头，然后才传给下一层，可将加上报头想象为套上一层信封。

因此到了最底层时，原本的数据已经套上了七层信封，而后通过网线、电话线、光纤等介质，传送到接收端。

接收端接收到数据后，从最底层向上层传送，每经过一层就拆掉一层信封(即去除该层所认识的报头)，直到最上层，数据便恢复成当初从传送端最上层产生时的原貌。

如果以网络的术语来说，这种每一层将原始数据加上报头的 *** 作，便是数据的封装，而封装前的原始数据则称为数据承载。在传送端，上层将数据传给下层，下层将上层传过来的数据当成数据承载，再将数据承载封装成新的数据，继续传给更下层去封装，直到最底层为止。

随着时间和业务的发展，数据库中的数据量增长是不可控的，库和表中的数据会越来越大，随之带来的是更高的 磁盘 、 IO 、 系统开销 ，甚至 性能 上的瓶颈，而单台服务器的 资源终究是有限 的。

因此在面对业务扩张过程中，应用程序对数据库系统的 健壮性 ， 安全性 ， 扩展性 提出了更高的要求。

以下，我从数据库架构、选型与落地来让大家入门。

数据库会面临什么样的挑战呢？

业务刚开始我们只用单机数据库就够了，但随着业务增长，数据规模和用户规模上升，这个时候数据库会面临IO瓶颈、存储瓶颈、可用性、安全性问题。

为了解决上述的各种问题，数据库衍生了出不同的架构来解决不同的场景需求。

将数据库的写 *** 作和读 *** 作分离，主库接收写请求，使用多个从库副本负责读请求，从库和主库同步更新数据保持数据一致性，从库可以水平扩展，用于面对读请求的增加。

这个模式也就是常说的读写分离，针对的是小规模数据，而且存在大量读 *** 作的场景。

因为主从的数据是相同的，一旦主库宕机的时候，从库可以 切换为主库提供写入 ，所以这个架构也可以提高数据库系统的 安全性 和 可用性 ；

优点：

缺点：

在数据库遇到 IO瓶颈 过程中，如果IO集中在某一块的业务中，这个时候可以考虑的就是垂直分库，将热点业务拆分出去，避免由 热点业务 的 密集IO请求 影响了其他正常业务，所以垂直分库也叫 业务分库 。

优点：

缺点：

在数据库遇到存储瓶颈的时候，由于数据量过大造成索引性能下降。

这个时候可以考虑将数据做水平拆分，针对数据量巨大的单张表，按照某种规则，切分到多张表里面去。

但是这些表还是在同一个库中，所以库级别的数据库 *** 作还是有IO瓶颈（单个服务器的IO有上限）。

所以水平分表主要还是针对 数据量较大 ，整体业务 请求量较低 的场景。

优点：

缺点：

四、分库分表

在数据库遇到存储瓶颈和IO瓶颈的时候，数据量过大造成索引性能下降，加上同一时间需要处理大规模的业务请求，这个时候单库的IO上限会限制处理效率。

所以需要将单张表的数据切分到多个服务器上去，每个服务器具有相应的库与表，只是表中数据集合不同。

分库分表能够有效地缓解单机和单库的 性能瓶颈和压力 ，突破IO、连接数、硬件资源等的瓶颈。

优点：

缺点：

注：分库还是分表核心关键是有没有IO瓶颈 。

分片方式都有什么呢？

RANGE（范围分片）

将业务表中的某个 关键字段排序 后，按照顺序从0到10000一个表，10001到20000一个表。最常见的就是 按照时间切分 （月表、年表）。

比如将6个月前，甚至一年前的数据切出去放到另外的一张表，因为随着时间流逝，这些表的数据被查询的概率变小，银行的交易记录多数是采用这种方式。

优点：

缺点：

HASH（哈希分片）

将订单作为主表，然后将其相关的业务表作为附表，取用户id然后 hash取模 ，分配到不同的数据表或者数据库上。

优点：

缺点：

讲到这里，我们已经知道数据库有哪些架构，解决的是哪些问题，因此， 我们在日常设计中需要根据数据的特点，数据的倾向性，数据的安全性等来选择不同的架构 。

那么，我们应该如何选择数据库架构呢？

虽然把上面的架构全部组合在一起可以形成一个强大的高可用，高负载的数据库系统，但是架构选择合适才是最重要的。

混合架构虽然能够解决所有的场景的问题，但是也会面临更多的挑战，你以为的完美架构，背后其实有着更多的坑。

1、对事务支持

分库分表后（无论是垂直还是水平拆分），就成了分布式事务了，如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的性能代价（XA事务）；如果由应用程序去协助控制，形成程序逻辑上的事务，又会造成编程方面的负担（TCC、SAGA）。

2、多库结果集合并 （group by，order by）

由于数据分布于不同的数据库中，无法直接对其做分页、分组、排序等 *** 作，一般应对这种多库结果集合并的查询业务都需要采用数据清洗、同步等其他手段处理（TIDB、KUDU等）。

3、数据延迟

主从架构下的多副本机制和水平分库后的聚合库都会存在主数据和副本数据之间的延迟问题。

4、跨库join

分库分表后表之间的关联 *** 作将受到限制，我们无法join位于不同分库的表（垂直），也无法join分表粒度不同的表（水平）， 结果原本一次查询就能够完成的业务，可能需要多次查询才能完成。

5、分片扩容

水平分片之后，一旦需要做扩容时。需要将对应的数据做一次迁移，成本代价都极高的。

6、ID生成

分库分表后由于数据库独立，原有的基于数据库自增ID将无法再使用，这个时候需要采用其他外部的ID生成方案。

一、应用层依赖类（JDBC）

这类分库分表中间件的特点就是和应用强耦合，需要应用显示依赖相应的jar包（以Java为例），比如知名的TDDL、当当开源的 sharding-jdbc 、蘑菇街的TSharding等。

此类中间件的基本思路就是重新实现JDBC的API，通过重新实现 DataSource 、 PrepareStatement 等 *** 作数据库的接口，让应用层在 基本 不改变业务代码的情况下透明地实现分库分表的能力。

中间件给上层应用提供熟悉的JDBC API，内部通过 sql解析 、 sql重写 、 sql路由 等一系列的准备工作获取真正可执行的sql，然后底层再按照传统的方法（比如数据库连接池）获取物理连接来执行sql，最后把数据 结果合并 处理成ResultSet返回给应用层。

优点

缺点

二、中间层代理类（Proxy）

这类分库分表中间件的核心原理是在应用和数据库的连接之间搭起一个 代理层 ，上层应用以 标准的MySQL协议 来连接代理层，然后代理层负责 转发请求 到底层的MySQL物理实例，这种方式对应用只有一个要求，就是只要用MySQL协议来通信即可。

所以用MySQL Navicat这种纯的客户端都可以直接连接你的分布式数据库，自然也天然 支持所有的编程语言 。

在技术实现上除了和应用层依赖类中间件基本相似外，代理类的分库分表产品必须实现标准的MySQL协议，某种意义上讲数据库代理层转发的就是MySQL协议请求，就像Nginx转发的是>

三层架构和MVC是有明显区别的,MVC应该是展现模式(三个加起来以后才是三层架构中的UI层) 三层架构(3-tier

application)

通常意义上的三层架构就是将整个业务应用划分为：表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL）。区分层次的目的即为了“高内聚，低耦合”的思想。

1、表现层（UI）：通俗讲就是展现给用户的界面，即用户在使用一个系统的时候他的所见所得。

2、业务逻辑层（BLL）：针对具体问题的 *** 作，也可以说是对数据层的 *** 作，对数据业务逻辑处理。

3、数据访问层（DAL）：该层所做事务直接 *** 作数据库，针对数据的增添、删除、修改、更新、查找等。

MVC是

Model-View-Controller，严格说这三个加起来以后才是三层架构中的UI层，也就是说，MVC把三层架构中的UI层再度进行了分化，分成了控制器、视图、实体三个部分，控制器完成页面逻辑，通过实体来与界面层完成通话；而C层直接与三层中的BLL进行对话。

mvc可以是三层中的一个表现层框架，属于表现层。三层和mvc可以共存。

三层是基于业务逻辑来分的，而mvc是基于页面来分的。

MVC主要用于表现层，3层主要用于体系架构，3层一般是表现层、中间层、数据层，其中表现层又可以分成M、V、C，(Model View

Controller)模型－视图－控制器

曾把MVC模式和Web开发中的三层结构的概念混为一谈，直到今天才发现一直是我的理解错误。MVC模式是GUI界面开发的指导模式，基于表现层分离的思想把程序分为三大部分：Model-View-Controller，呈三角形结构。Model是指数据以及应用程序逻辑，View是指

Model的视图，也就是用户界面。这两者都很好理解，关键点在于Controller的角色以及三者之间的关系。在MVC模式中，Controller和View同属于表现层，通常成对出现。Controller被设计为处理用户交互的逻辑。一个通常的误解是认为Controller负责处理View和Model的交互，而实际上View和Model之间是可以直接通信的。由于用户的交互通常会涉及到Model的改变和View的更新，所以这些可以认为是Controller的副作用。

MVC是表现层的架构，MVC的Model实际上是ViewModel，即供View进行展示的数据。

ViewModel不包含业务逻辑，也不包含数据读取。

而在N层架构中，一般还会有一个Model层，用来与数据库的表相对应，也就是所谓ORM中的O。这个Model可能是POCO，也可能是包含一些验证逻辑的实体类，一般也不包含数据读取。进行数据读取的是数据访问层。而作为UI层的MVC一般不直接 *** 作数据访问层，中间会有一个业务逻辑层封装业务逻辑、调用数据访问层。UI层（Controller）通过业务逻辑层来得到数据（Model），并进行封装（ViewModel），然后选择相应的View。

MVC本来是存在于Desktop程序中的，M是指数据模型，V是指用户界面，C则是控制器。使用MVC的目的是将M和V的实现代码分离，从而使同一个程序可以使用不同的表现形式。比如一批统计数据你可以分别用柱状图、饼图来表示。C存在的目的则是确保M和V的同步，一旦M改变，V应该同步更新。

MVC如何工作

MVC是一个设计模式，它强制性的使应用程序的输入、处理和输出分开。使用MVC应用程序被分成三个核心部件：模型、视图、控制器。它们各自处理自己的任务。

视图V

视图是用户看到并与之交互的界面。对老式的Web应用程序来说，视图就是由HTML元素组成的界面，在新式的Web应用程序中，HTML依旧在视图中扮演着重要的角色，但一些新的技术已层出不穷，它们包括Macromedia

Flash和象XHTML，XML/XSL，WML等一些标识语言和Web services

如何处理应用程序的界面变得越来越有挑战性。MVC一个大的好处是它能为你的应用程序处理很多不同的视图。在视图中其实没有真正的处理发生，不管这些数据是联机存储的还是一个雇员列表，作为视图来讲，它只是作为一种输出数据并允许用户 *** 纵的方式。

模型M

模型表示企业数据和业务规则。在MVC的三个部件中，模型拥有最多的处理任务。被模型返回的数据是中立的，就是说模型与数据格式无关，这样一个模型能为多个视图提供数据。由于应用于模型的代码只需写一次就可以被多个视图重用，所以减少了代码的重复性。

控制器C

控制器接受用户的输入并调用模型和视图去完成用户的需求。所以当单击Web页面中的超链接和发送HTML表单时，控制器本身不输出任何东西和做任何处理。它只是接收请求并决定调用哪个模型构件去处理请求，然后再确定用哪个视图来显示返回的数据。

模型Model 模型是应用程序的主体部分。模型表示业务数据，或者业务逻辑 实现具体的业务逻辑、状态管理的功能。 视图View

视图是应用程序中用户界面相关的部分，是用户看到并与之交互的界面。 就是与用户实现交互的页面，通常实现数据的输入和输出功能。

控制器controller

控制器工作就是根据用户的输入，控制用户界面数据显示和更新model对象状态。起到控制整个业务流程的作用，实现View层跟Model层的协同工作。

3层架构指:表现层(显示层)

业务逻辑层 数据访问层(持久化)如果大家非要“生搬硬套”把它和MVC扯上关系话那我就只能在这里"强扭这个瓜"了即: V

3层架构中"表现层"aspx页面对应MVC中View(继承的类不一样) C

三层架构中"表现层"的aspxcs页面(类)对应MVC中的Controller,理解这一点并不难，大家想一想我们以前写过的

Redirect，当然它本身就是跳转了一些链接页面，而MVC中的Controller要做的更爽，它控制并显示输出了一个视图。即然所起到的作用都是对业务流程和显示信息的控制，只不过是实现手段不同而已。

M

3层架构中业务逻辑层和数据访问层对应MVC中Model(必定View和Controller已找到“婆家”剩下Model只能是业务逻辑层和数据访问层了)

为什么要使用

MVC

大部分Web应用程序都是用像ASP，PHP，或者CFML这样的过程化(自PHP50版本后已全面支持面向对象模型)语言来创建的。它们将像数据库查询语句这样的数据层代码和像HTML这样的表示层代码混在一起。经验比较丰富的开发者会将数据从表示层分离开来，但这通常不是很容易做到的，它需要精心的计划和不断的尝试。MVC从根本上强制性的将它们分开。尽管构造MVC应用程序需要一些额外的工作，但是它给我们带来的好处是无庸质疑的。

首先，最重要的一点是多个视图能共享一个模型，现在需要用越来越多的方式来访问你的应用程序。对此，其中一个解决之道是使用MVC，无论你的用户想要Flash界面或是

WAP 界面；用一个模型就能处理它们。由于你已经将数据和业务规则从表示层分开，所以你可以最大化的重用你的代码了。

由于模型返回的数据没有进行格式化，所以同样的构件能被不同界面使用。例如，很多数据可能用HTML来表示，但是它们也有可能要用Adobe

Flash和WAP来表示。模型也有状态管理和数据持久性处理的功能，例如，基于会话的购物车和电子商务过程也能被Flash网站或者无线联网的应用程序所重用。

因为模型是自包含的，并且与控制器和视图相分离，所以很容易改变你的应用程序的数据层和业务规则。如果你想把你的数据库从MySQL移植到Oracle，或者改变你的基于RDBMS数据源到LDAP，只需改变你的模型即可。一旦你正确的实现了模型，不管你的数据来自数据库或是LDAP服务器，视图将会正确的显示它们。由于运用MVC的应用程序的三个部件是相互独立，改变其中一个不会影响其它两个，所以依据这种设计思想你能构造良好的松耦合的构件。

对我来说，控制器也提供了一个好处，就是可以使用控制器来联接不同的模型和视图去完成用户的需求，这样控制器可以为构造应用程序提供强有力的手段。给定一些可重用的模型和视图，控制器可以根据用户的需求选择模型进行处理，然后选择视图将处理结果显示给用户。

拿一个简单的登陆模块说，需求是你输入一个用户名、密码，如果输入的跟预先定义好的一样，那么就进入到正确页面，如果不一样，就提示个错误信息“你Y别在这儿蒙我，输入的不对！”。

V 这个小小的模块中，起始的输入用户名密码的页面跟经过校验后显示的页面就相当于View C

而这里还需要一个controller页面，就是用于接收输入进来的用户名密码，还有经过校验后返回的一个flg（此flg就是用于判断你输入的是否正确，而跳转到相应的页面的）

M 最后还缺一个Model，那么就是你那个用于校验的类了，他就是处理你输入的是否跟预先订好的一样不一样的，之后返回一个flg。

这样就完全实现了逻辑跟页面的分离，我页面不管你咋整，反正我就一个显示，而controller呢也不管你Model咋判断对不对，反正我给你了用户名跟密码，你就得给我整回来一个flg来，而Medol呢，则是反正你敢给我个用户名跟密码，我就给你整过去个flg

m 提供数据，数据之间的关系，转化等。并可以通知视图和控制器自己哪些地方发生了变化。 v 提供显示，能根据m的改变来更新自己 c

比如视图做了点击一个按钮，会先发给这个视图的控制器，然后这个控制器来决定做什么 *** 作(让模型更新数据，控制视图改变) mvc是一个复合模式

mv，mc都是观察者模式 m内部的组件组合模式 vc之间是策略模式(可以随时更换不同的控制器)

MVC模式是上世纪70年代提出，最初用于Smalltalk平台上的。

MVC是表现模式，是用来向用户展现的许多组建的一个模式（UI/Presentation Patten） MVC有三种角色：

Model：用来储存数据的组件（与领域模型概念不同，两者会相互交叉）

View：从Model中获取数据进行内容展示的组件。同样的Model在不同的View下可展示不同的效果。获取Model的状态，而不对其进行 *** 作。

Controller：接受并处理用户指令（ *** 作Model（业务）），选择一个View进行 *** 作。

MVC概述：协作 存在单向引用，例如Model不知道View和Controller的存在。View不知道Controller的存在。这就隔离了表现和数据。View和controller是单向引用。而实际中View和Controller也是有数据交互的。

MVC的重要特点是分离。两种分离： View和数据(Model)的分离

使用不同的View对相同的数据进行展示；分离可视和不可视的组件，能够对Model进行独立测试。因为分离了可视组件减少了外部依赖利于测试。（数据库也是一种外部组件）

View和表现逻辑(Controller)的分离

Controller是一个表现逻辑的组件，并非一个业务逻辑组件。MVC可以作为表现模式也可以作为建构模式，意味这Controller也可以是业务逻辑。分离逻辑和具体展示，能够对逻辑进行独立测试。

MVC和三层架构 MVC与三层架构类似么？ View-UI Layer | Controller-Bussiness Layer

| Model-Data Access Layer 其实这样是错误的 MVC是表现模式（Presentation Pattern）

三层架构是典型的架构模式（Architecture Pattern）

三层架构的分层模式是典型的上下关系，上层依赖于下层。但MVC作为表现模式是不存在上下关系的，而是相互协作关系。即使将MVC当作架构模式，也不是分层模式。MVC和三层架构基本没有可比性，是应用于不同领域的技术。

MVC模式与三层架构:

ui (view)←(contorller)

bll (model)

dal (model)

1、表现层：主要功能是显示数据和接受传输用户的数据，可以在为网站的系统运行提供交互式 *** 作界面，表现层的应用方式比较常见，例如Windows窗体和Web页面。

2、控制层：将业务规则、数据访问、合法性校验等工作进行处理。通过COM/DCOM通讯与逻辑层建立连接。

3、逻辑层：将用户的输入信息进行甄别处理，分别保存。建立新的数据存储方式，在存储过程中对数据进行读取，将“商业逻辑”描述代码进行包含。

4、DAO层：主要是对非原始数据（数据库或者文本文件等存放数据的形式）的 *** 作层，对数据库的 *** 作，而不是数据，具体为业务逻辑层或控制层提供数据服务。

5、最终数据库：是数据库的主要 *** 控系统，实现数据的增加、删除、修改、查询等 *** 作。实际运行的过程中，最终数据库没有逻辑判断能力，为了实现代码编写的严谨性，提高代码阅读程度，一般软件开发人员会使用DAO层，保证数据处理功能。

扩展资料：

系统分为表现层、控制层、逻辑层、DAO层和最终数据库五层架构的优点是：

1、开发人员可以只关注整个结构中的其中某一层。

2、可以很容易的用新的实现来替换原有层次的实现。

3、可以降低层与层之间的依赖。

4、有利于标准化。

5、利于各层逻辑的复用。

6、结构更加的明确。

7、在后期维护的时候，极大地降低了维护成本和维护时间。

8、避免了表示层直接访问数据访问层，表示层只和业务逻辑层有联系，提高了数据安全性。

9、有利于系统的分散开发，每一个层可以由不同的人员来开发，只要遵循接口标准，利用相同的对象模型实体类就可以了，这样就可以大大提高系统的开发速度。

10、方便系统的移植，如果要把一个C/S的系统变成B/S系统，只要修改三层架构的表示层就可以了。业务逻辑层和数据访问层几乎不用修改就可以轻松的把系统移植到网络上。

11、项目结构更清楚，分工更明确，有利于后期的维护和升级。

基于web和基于ssm的区别分别是：

基于Java Web常见的三层结构是：

1、表现层：也就是Web层，常见的框架有Spring MVC、Struts2 ，并包括用于展示的界面，如JSP界面；

2、业务层：Service层，专注于业务逻辑的实现；

3、持久层：也叫Dao层，常见的框架是Hibernate、MyBatis。负责与数据库的交互，封装数据库的访问细节。

从数据库表中读取加载数据并实例化领域对象（Domian Object）也就是从数据库中读取数据，或者返过来将领域对象实例化到数据库中，也就是将数据写入到数据库中。

Java在SSM框架中的体现是：

1、POJO层： 由一组POJO组成，是对系统各种对象的抽象表达。

2、DAO层： 负责数据库的访问，增、删、改、查等，在MyBatis框架中也常被定义为Mapper层。

3、Service层：由业务逻辑对象组成，是不同系统的业务逻辑的具体实现。

4、Controller层：由控制器组成，对来自浏览器的用户请求进行拦截，并调用Service层的响应的业务逻辑组件处理用户请求，并转发返回结果到View层。

5、View层：由JSP界面，PDF文档等组件组成，用于显示系统对用户请求的处理结果。

SSM框架中各框架的作用是：

1、MyBatis：持久层框架，负责数据库访问。

2、Spring MVC：表现层框架，把模型、视图、控制器分离，组合成一个灵活的系统。

3、Spring： 整合项目的所有框架，管理各种Java Bean（mapper、service、controller），事务控制。

以上就是关于请问JAVA三层架构，持久层，业务层，表现层，都该怎么理解和MVC三层模型有什么全部的内容，包括:请问JAVA三层架构，持久层，业务层，表现层，都该怎么理解和MVC三层模型有什么、OSI参考模型分为七层，从低到高依次是、数据库架构选型与落地，看这篇就够了等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！