❶ MVC三层框架概述
MVC（模型Model-视图View-控制器Controller）是一种设计模式，
MVC。V即View.是视图的意思。C即Controller.是控制器的意思。而M即Model，是模型的意思。这三个里.最不容易理解的应该是Model.就是什么是Model，而为什么叫Model。我先不说为什么叫Model，先解释Controller。
Controller是控制器的意思，所谓控制器，就是将用户请求转发给模型层，经过处理后把结果返回到界面层展现的一个中间层，那么Controller到底管什么工作呢？先不说.先来看下在Java Web中这三个层一般的定义，一般在Java Web里，JSP充当V，Servlet充当C,JavaBean充当M，这里的Servlet管什么工作呢？接受输入，转到Model层去处理，处理结果保存后转发到JSP，然后展现数据。所以它的功能就是控制器的基本功能，它就管转发，在V和M之间转来转去。
再来说说M，即Model，在Java Web里说的是JavaBean，我认识的很多人都把JavaBean误认为是实体类，其实JavaBean有比实体类更丰富的定义，在JavaBean中除了其属性和字段，还可以有行为及其事件，JavaBean可以理解为普通Java对象。Java普通对象，就是符合Java规范的所有对象，这和实体类完全是两回事。所以，我认为在MVC中。业务逻辑和数据访问应该放在Model层，也就是V负责展示数据，Controler除了转发不做业务逻辑。真正的逻辑事务，数据访问，甚至算法都放到Model去。
MVC没有把业务的逻辑访问看成两个层，这是采用三层架构或MVC搭建程序最主要的区别。当然了。在三层中也提到了Model，但是三层架构中Model的概念与MVC中Model的概念是不一样的，“三层”中典型的Model层是已实体类构成的，而MVC里，则是由业务逻辑与访问数据组成的。
❷ java设计问题什么是MVC设计模式和三层架构有什么区别，它们是不是一个意思
当然不是一个意思了，基于Java 的Web 应用系统采用MVC 架构模式，即model（模型）、view（视图）、control（控制）分离设计；这是目前WEB 应用服务系统的主流设计方向。
Model：即处理业务逻辑的模块，每一种处理一个模块；
View：负责页面显示，显示MODEL 处理结果给用户，主要实现数据到页面转换过程；
Control：负责每个请求的分发，把FORM 数据传递给MODEL 处理，把处理结果的数据传递给VIEW 显示。
❸ 什么是MVC(三层架构)
MVC是一个设计模式，它强制性的使应用程序的输入、处理和输出分开。使用MVC应用程序被分成三个核心部件：模型、视图、控制器。它们各自处理自己的任务。
视图视图是用户看到并与之交互的界面。对老式的Web应用程序来说，视图就是由HTML元素组成的界面，在新式的Web应用程序中，HTML依旧在视图中扮演着重要的角色，但一些新的技术已层出不穷，它们包括MacromediaFlash和象XHTML，XML/XSL，WML等一些标识语言和Webservices.
模型模型表示企业数据和业务规则。在MVC的三个部件中，模型拥有最多的处理任务。例如它可能用象EJBs和ColdFusionComponents这样的构件对象来处理数据库。被模型返回的数据是中立的，就是说模型与数据格式无关，这样一个模型能为多个视图提供数据。由于应用于模型的代码只需写一次就可以被多个视图重用，所以减少了代码的重复性。
控制器控制器接受用户的输入并调用模型和视图去完成用户的需求。所以当单击Web页面中的超链接和发送HTML表单时，控制器本身不输出任何东西和做任何处理。它只是接收请求并决定调用哪个模型构件去处理请求，然后用确定用哪个视图来显示模型处理返回的数据。
现在我们总结ＭVC的处理过程，首先控制器接收用户的请求，并决定应该调用哪个模型来进行处理，然后模型用业务逻辑来处理用户的请求并返回数据，最后控制器用相应的视图格式化模型返回的数据，并通过表示层呈现给用户。
大部分Web应用程序都是用像ASP，PHP，或者CFML这样的过程化语言来创建的。它们将像数据库查询语句这样的数据层代码和像HTML这样的表示层代码混在一起。经验比较丰富的开发者会将数据从表示层分离开来，但这通常不是很容易做到的，它需要精心的计划和不断的尝试。MVC从根本上强制性的将它们分开。尽管构造MVC应用程序需要一些额外的工作，但是它给我们带来的好处是无庸质疑的。
首先，最重要的一点是多个视图能共享一个模型，正如我所提及的，现在需要用越来越多的方式来访问你的应用程序。对此，其中一个解决之道是使用MVC，无论你的用户想要Flash界面或是 WAP 界面；用一个模型就能处理它们。由于你已经将数据和业务规则从表示层分开，所以你可以最大化的重用你的代码了。
由于模型返回的数据没有进行格式化，所以同样的构件能被不同界面使用。例如，很多数据可能用HTML来表示，但是它们也有可能要用Macromedia Flash和WAP来表示。模型也有状态管理和数据持久性处理的功能，例如，基于会话的购物车和电子商务过程也能被Flash网站或者无线联网的应用程序所重用。
因为模型是自包含的，并且与控制器和视图相分离，所以很容易改变你的应用程序的数据层和业务规则。如果你想把你的数据库从MySQL移植到Oracle，或者改变你的基于RDBMS数据源到LDAP，只需改变你的模型即可。一旦你正确的实现了模型，不管你的数据来自数据库或是LDAP服务器，视图将会正确的显示它们。由于运用MVC的应用程序的三个部件是相互对立，改变其中一个不会影响其它两个，所以依据这种设计思想你能构造良好的松偶合的构件。
对我来说，控制器的也提供了一个好处，就是可以使用控制器来联接不同的模型和视图去完成用户的需求，这样控制器可以为构造应用程序提供强有力的手段。给定一些可重用的模型和视图，控制器可以根据用户的需求选择模型进行处理，然后选择视图将处理结果显示给用户。
MVC的缺点MVC的缺点是由于它没有明确的定义，所以完全理解MVC并不是很容易。使用MVC需要精心的计划，由于它的内部原理比较复杂，所以需要花费一些时间去思考。
根据我个人经验，由于我们将一个应用程序分成了三个部件，所以使用MVC同时也意味着你将要管理比以前更多的文件，这一点是显而易见的。这样好像我们的工作量增加了，但是请记住这比起它所能带给我们的好处是不值一提。
MVC并不适合小型甚至中等规模的应用程序，花费大量时间将MVC应用到规模并不是很大的应用程序通常会得不偿失。
MVC是一条创建软件的好途径
MVC设计模式是一个很好创建软件的途径，它所提倡的一些原则，像内容和显示互相分离可能比较好理解。但是如果你要隔离模型、视图和控制器的构件，你可能需要重新思考你的应用程序，尤其是应用程序的构架方面。如果你肯接受MVC，并且有能力应付它所带来的额外的工作和复杂性，MVC将会使你的软件在健壮性，代码重用和结构方面上一个新的台阶。
Java开发Web Application有几种符合MVC设计模式的开发方式。
1:Jsp+Servlet+JavaBean(EJB)
2:Jsp+JavaBean(Controller)+JavaBean(EJB)(Model)
3:TDK(Turbine，Velocity...)
4:Xsp5:Jsp+Struts+JavaBean(EJB)附：三层架构即“表现层”，“业务层”，“持久化层”。表现层实现的代表作品是Struts框架，业务层实现的代表作品是Spring，持久层实现的代表作品是Hibernate。
举个例子。
持久层从持久库中取出-10。
业务层按照一定的逻辑（这里我们举例取温度的逻辑）翻译成-10摄氏度。
表示层显现给用户“哎呀，今天好冷！”。
❹ 三层架构和mvc模式是什么技术
三层架构是一个分层式的软件体系架构设计，它可适用于任何一个项目。三层架构将整个项目划分为：表现层(ui)、业务逻辑层(bll)、数据访问层(dal)。
mvc是一个设计模式，它是根据项目的具体需求来决定是否适用于该项目。mvc可分为：model模型层、view视图层、controller控制层;
总结：在java
web开发中，mvc框架充当了ui层和业务逻辑层的适配器的作用。mvc框架实现了ui层和业务逻辑层最大程度的分离。
❺ java中 MVC 三层架构
MVC模式是"Model-View-Controller"的缩写，中文翻译为"模式-视图-控制器"。MVC应用程序总是由这三个部分组成。Event(事件)导致Controller改变Model或View，或者同时改变两者。只要Controller改变了Models的数据或者属性，所有依赖的View都会自动更新。类似的，只要Controller改变了View，View会从潜在的Model中获取数据来刷新自己。MVC模式最早是smalltalk语言研究团提出的，应用于用户交互应用程序中。smalltalk语言和java语言有很多相似性,都是面向对象语言，很自然的SUN在petstore(宠物店)事例应用程序中就推荐MVC模式作为开发Web应用的架构模式。MVC模式是一种架构模式，其实需要其他模式协作完成。在J2EE模式目录中，通常采用service to worker模式实现，而service to worker模式可由集中控制器模式，派遣器模式和Page Helper模式组成。而Struts只实现了MVC的View和Controller两个部分，Model部分需要开发者自己来实现，Struts提供了抽象类Action使开发者能将Model应用于Struts框架中。
MVC模式是一个复杂的架构模式，其实现也显得非常复杂。但是，我们已经终结出了很多可靠的设计模式，多种设计模式结合在一起，使MVC模式的实现变得相对简单易行。Views可以看作一棵树，显然可以用Composite Pattern来实现。Views和Models之间的关系可以用Observer Pattern体现。Controller控制Views的显示，可以用Strategy Pattern实现。Model通常是一个调停者，可采用Mediator Pattern来实现。
现在让我们来了解一下MVC三个部分在J2EE架构中处于什么位置，这样有助于我们理解MVC模式的实现。MVC与J2EE架构的对应关系是:View处于Web Tier或者说是Client Tier，通常是JSP/Servlet，即页面显示部分。Controller也处于Web Tier，通常用Servlet来实现，即页面显示的逻辑部分实现。Model处于Middle Tier，通常用服务端的javaBean或者EJB实现，即业务逻辑部分的实现。
一、MVC设计思想
MVC英文即Model-View-Controller，即把一个应用的输入、处理、输出流程按照Model、View、Controller的方式进行分离，这样一个应用被分成三个层——模型层、视图层、控制层。
视图(View)代表用户交互界面，对于Web应用来说，可以概括为HTML界面，但有可能为XHTML、XML和Applet。随着应用的复杂性和规模性，界面的处理也变得具有挑战性。一个应用可能有很多不同的视图，MVC设计模式对于视图的处理仅限于视图上数据的采集和处理，以及用户的请求，而不包括在视图上的业务流程的处理。业务流程的处理交予模型(Model)处理。比如一个订单的视图只接受来自模型的数据并显示给用户，以及将用户界面的输入数据和请求传递给控制和模型。
模型(Model)：就是业务流程/状态的处理以及业务规则的制定。业务流程的处理过程对其它层来说是黑箱操作，模型接受视图请求的数据，并返回最终的处理结果。业务模型的设计可以说是MVC最主要的核心。目前流行的EJB模型就是一个典型的应用例子，它从应用技术实现的角度对模型做了进一步的划分，以便充分利用现有的组件，但它不能作为应用设计模型的框架。它仅仅告诉你按这种模型设计就可以利用某些技术组件，从而减少了技术上的困难。对一个开发者来说，就可以专注于业务模型的设计。MVC设计模式告诉我们，把应用的模型按一定的规则抽取出来，抽取的层次很重要，这也是判断开发人员是否优秀的设计依据。抽象与具体不能隔得太远，也不能太近。MVC并没有提供模型的设计方法，而只告诉你应该组织管理这些模型，以便于模型的重构和提高重用性。我们可以用对象编程来做比喻，MVC定义了一个顶级类，告诉它的子类你只能做这些，但没法限制你能做这些。这点对编程的开发人员非常重要。
业务模型还有一个很重要的模型那就是数据模型。数据模型主要指实体对象的数据 保存（持续化）。比如将一张订单保存到数据库，从数据库获取订单。我们可以将这个模型单独列出，所有有关数据库的操作只限制在该模型中。
控制(Controller)可以理解为从用户接收请求, 将模型与视图匹配在一起，共同完成用户的请求。划分控制层的作用也很明显，它清楚地告诉你，它就是一个分发器，选择什么样的模型，选择什么样的视图，可以完成什么样的用户请求。控制层并不做任何的数据处理。例如，用户点击一个连接，控制层接受请求后, 并不处理业务信息，它只把用户的信息传递给模型，告诉模型做什么，选择符合要求的视图返回给用户。因此，一个模型可能对应多个视图，一个视图可能对应多个模型。
模型、视图与控制器的分离，使得一个模型可以具有多个显示视图。如果用户通过某个视图的控制器改变了模型的数据，所有其它依赖于这些数据的视图都应反映到这些变化。因此，无论何时发生了何种数据变化，控制器都会将变化通知所有的视图，导致显示的更新。这实际上是一种模型的变化-传播机制。模型、视图、控制器三者之间的关系和各自的主要功能，如图1所示。
二、MVC设计模式的实现
ASP.NET提供了一个很好的实现这种经典设计模式的类似环境。开发者通过在ASPX页面中开发用户接口来实现视图；控制器的功能在逻辑功能代码(.cs)中实现；模型通常对应应用系统的业务部分。在ASP.NET中实现这种设计而提供的一个多层系统，较经典的ASP结构实现的系统来说有明显的优点。将用户显示（视图）从动作（控制器）中分离出来,提高了代码的重用性。将数据（模型）从对其操作的动作（控制器）分离出来可以让你设计一个与后台存储数据无关的系统。就MVC结构的本质而言，它是一种解决耦合系统问题的方法。
2.1 视图
视图是模型的表示，它提供用户交互界面。使用多个包含单显示页面的用户部件，复杂的Web页面可以展示来自多个数据源的内容，并且网页人员，美工能独自参与这些Web页面的开发和维护。
在ASP.NET下，视图的实现很简单。可以像开发WINDOWS界面一样直接在集成开发环境下通过拖动控件来完成页面开发本。本文中介绍每一个页面都采用复合视图的形式即：一个页面由多个子视图(用户部件)组成；子视图可以是最简单HTML 控件、服务器控件或多个控件嵌套构而成的Web自定义控件。页面都由模板定义，模板定义了页面的布局，用户部件的标签和数目，用户指定一个模板，平台根据这些信息自动创建页面。针对静态的模板内容，如页面上的站点导航，菜单，友好链接，这些使用缺省的模板内容配置；针对动态的模板内容(主要是业务内容)，由于用户的请求不同，只能使用后期绑定，并且针对用户的不同，用户部件的显示内容进行过滤。使用由用户部件根据模板配置组成的组合页面，它增强了可重用性，并原型化了站点的布局。
视图部分大致处理流程如下：首先，页面模板定义了页面的布局；页面配置文件定义视图标签的具体内容（用户部件）；然后，由页面布局策略类初始化并加载页面；每个用户部件根据它自己的配置进行初始化，加载校验器并设置参数，以及事件的委托等；用户提交后，通过了表示层的校验，用户部件把数据自动提交给业务实体即模型。
这一部分主要定义了WEB页面基类PageBase；页面布局策略类PageLayout，完成页面布局，用于加载用户部件到页面；用户部件基类UserControlBase即用户部件框架，用于动态加载检验部件，以及实现用户部件的个性化。为了实现WEB应用的灵活性，视图部分也用到了许多配置文件例如：置文件有模板配置、页面配置、路径配置、验证配置等。
2.2 控制器
为了能够控制和协调每个用户跨越多个请求的处理，控制机制应该以集中的方式进行管理。因此，为了达到集中管理的目的引入了控制器。应用程序的控制器集中从客户端接收请求（典型情况下是一个运行浏览器的用户），决定执行什么商业逻辑功能，然后将产生下一步用户界面的责任委派给一个适当的视图组件。
用控制器提供一个控制和处理请求的集中入口点，它负责接收、截取并处理用户请求；并将请求委托给分发者类，根据当前状态和业务操作的结果决定向客户呈现的视图。在这一部分主要定义了HttpReqDispatcher(分发者类)、HttpCapture(请求捕获者类)、Controller(控制器类)等，它们相互配合来完成控制器的功能。请求捕获者类捕获HTTP请求并转发给控制器类。控制器类是系统中处理所有请求的最初入口点。控制器完成一些必要的处理后把请求委托给分发者类；分发者类分发者负责视图的管理和导航，它管理将选择哪个视图提供给用户，并提供给分发资源控制。在这一部分分别采用了分发者、策略、工厂方法、适配器等设计模式。
为了使请求捕获者类自动捕获用户请求并进行处理，ASP.NET 提供低级别的请求/响应 API，使开发人员能够使用 .NET 框架类为传入的 HTTP 请求提供服务。为此，必须创作支持 System.Web.IHTTPHandler 接口和实现 ProcessRequest() 方法的类即：请求捕获者类，并在web.config 的 ＜httphandlers＞ 节中添加类。ASP.NET 收到的每个传入 HTTP 请求最终由实现 IHTTPHandler 的类的特定实例来处理。IHttpHandlerFactory 提供了处理 IHttpHandler 实例 URL 请求的实际解析的结构。HTTP 处理程序和工厂在 ASP.NET 配置中声明为 web.config 文件的一部分。ASP.NET 定义了一个 ＜httphandlers＞ 配置节，在其中可以添加和移除处理程序和工厂。子目录继承 HttpHandlerFactory 和 HttpHandler 的设置。 HTTP 处理程序和工厂是 ASP.NET 页框架的主体。工厂将每个请求分配给一个处理程序，后者处理该请求。 例如，在全局 machine.config 文件中，ASP.NET 将所有对 ASPx 文件的请求映射到 HttpCapture类：
＜httphandlers＞
...
...
＜/httphandlers＞
2.3 模型
MVC系统中的模型从概念上可以分为两类――系统的内部状态和改变系统状态的动作。模型是你所有的商业逻辑代码片段所在。本文为模型提供了业务实体对象和业务处理对象：所有的业务处理对象都是从ProcessBase类派生的子类。业务处理对象封装了具体的处理逻辑，调用业务逻辑模型，并且把响应提交到合适的视图组件以产生响应。业务实体对象可以通过定义属性描述客户端表单数据。所有业务实体对象都EntityBase派生子类对象，业务处理对象可以直接对它进行读写，而不再需要和request、response对象进行数据交互。通过业务实体对象实现了对视图和模型之间交互的支持。实现时把"做什么"（业务处理）和"如何做"（业务实体）分离。这样可以实现业务逻辑的重用。由于各个应用的具体业务是不同的，这里不再列举其具体代码实例。
三、MVC设计模式的扩展
通过在ASP.NET中的MVC模式编写的，具有极其良好的可扩展性。它可以轻松实现以下功能：
①实现一个模型的多个视图；
②采用多个控制器；
③当模型改变时，所有视图将自动刷新；
④所有的控制器将相互独立工作。
这就是MVC模式的好处，只需在以前的程序上稍作修改或增加新的类，即可轻松增加许多程序功能。以前开发的许多类可以重用，而程序结构根本不再需要改变，各类之间相互独立，便于团体开发，提高开发效率。下面讨论如何实现一个模型、两个视图和一个控制器的程序。其中模型类及视图类根本不需要改变，与前面的完全一样，这就是面向对象编程的好处。对于控制器中的类，只需要增加另一个视图，并与模型发生关联即可。该模式下视图、控制器、模型三者之间的示意图如图2所示。
同样也可以实现其它形式的MVC例如：一个模型、两个视图和两个控制器。从上面可以看出，通过MVC模式实现的应用程序具有极其良好的可扩展性，是ASP.NET面向对象编程的未来方向。
四、MVC的优点
大部分用过程语言比如ASP、PHP开发出来的Web应用，初始的开发模板就是混合层的数据编程。例如，直接向数据库发送请求并用HTML显示,开发速度往往比较快,但由于数据页面的分离不是很直接,因而很难体现出业务模型的样子或者模型的重用性。产品设计弹性力度很小，很难满足用户的变化性需求。MVC要求对应用分层，虽然要花费额外的工作，但产品的结构清晰，产品的应用通过模型可以得到更好地体现。
首先，最重要的是应该有多个视图对应一个模型的能力。在目前用户需求的快速变化下，可能有多种方式访问应用的要求。例如，订单模型可能有本系统的订单，也有网上订单，或者其他系统的订单，但对于订单的处理都是一样，也就是说订单的处理是一致的。按MVC设计模式，一个订单模型以及多个视图即可解决问题。这样减少了代码的复制，即减少了代码的维护量，一旦模型发生改变，也易于维护。 其次，由于模型返回的数据不带任何显示格式，因而这些模型也可直接应用于接口的使用。
再次，由于一个应用被分离为三层，因此有时改变其中的一层就能满足应用的改变。一个应用的业务流程或者业务规则的改变只需改动MVC的模型层。
控制层的概念也很有效，由于它把不同的模型和不同的视图组合在一起完成不同的请求，因此，控制层可以说是包含了用户请求权限的概念。
最后，它还有利于软件工程化管理。由于不同的层各司其职，每一层不同的应用具有某些相同的特征，有利于通过工程化、工具化产生管理程序代码。
五、MVC的不足
MVC的不足体现在以下几个方面：
（1）增加了系统结构和实现的复杂性。对于简单的界面，严格遵循MVC，使模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。
（2）视图与控制器间的过于紧密的连接。视图与控制器是相互分离，但确实联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。
（3）视图对模型数据的低效率访问。依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。
（4） 目前，一般高级的界面工具或构造器不支持MVC模式。改造这些工具以适应MVC需要和建立分离的部件的代价是很高的，从而造成使用MVC的困难。
❻ 请问JAVA三层架构、持久层、业务层、表现层都该怎么理解和MVC三层模型有什么区别
希望还有人关注这个问题。
我们常常提到java EE的三层或者四层结构。
四层架构：
展示层（web层）、业务逻辑层、数据访问层、信息资源层
四层架构在是开发企业应用时使用的非常经典的划分模式。
web层负责前端展示和用户请求的处理。mvc是一个设计模式，主要用户构建用户界面，目的是把展示逻辑和逻辑分离。web层通常会使用MVC模式进行构建，经常使用的mvc框架包括spring mvc，struts等，都是在web层或者展示层使用的。
业务逻辑层一般应用中会有一层service抽象，实现核心业务逻辑，事务控制也在这一层实现。
数据访问层也即层，重点负责数据库访问，完成持久化功能。
信息资源层主要服务资源的存储。
所以mvc和四层（三层）结构有关系，四层架构是应用的体系（分层）结构，描述了整个应用的一个完整的划分，而mvc是一个设计模式，通常会用于四层架构的展示层的构建上。希望我能讲清楚。
❼ java mvc的三层架构是什么
持久层用来固化数据，如常说的DAO层，操作数据库将数据入库业务层用来实现整体的业务逻辑如前台获得了数据，逻辑层去解析这些数据，效验这些数据等操作表现层很好解释你现在看到的网页一些界面都属于表现层的东西可以用一些Html，jsp，Swing来
实现至于mvc么对应的是model（模型）view（视图）Controller（控制）在javaweb中就很好理解了再XX系统中，前台页面属于
view贯穿前台后台持久层的一套模型就是model（EJB，Spring来实现）而连接前台后台进行逻辑操作的就是
Controller（Struts来实现）这是最简单的说法懂吗？不懂说明真心菜，如果你真心想学习java可以加我们群来学习，群里每天都有分享课哦免费的视频资料一堆的。但是不是想学的就不要来了，要的加入23-129-41-89，我们喜欢java对它有独特的见解和学习方式。但交流是促进技术的最好方式。
❽ Java中的mvc和三层结构究竟是什么关系
一件事，要知其然往往很简单，要知其所以然通常不是那么容易，就如最近重新巩固spring的过程中，就觉得还有许多问题其实并不是十分明了。
屈指一算，手头上做过的正式项目也有了四五六七个了，不管用的数据库和其他一些细节上的技术如何，总的来说大的框架结构都是差不多的。
说白了，也就是mvc和三层结构。
而mvc和三层结构究竟是什么关系，我曾在面试的过程中被人问过几次，也曾仔细的想过、查过这个问题，但是直到此时，我也还是不能完全确定。
只不过随着时间的积累，随着技术的沉淀，随着视野的拓宽，我大体上认同了两种说法，不管别人怎么看，我个人是觉得两种说法都有道理，欢迎对这个问题有不同看法的朋友一起讨论。
三层结构是什么，是展现层、应用层、数据访问层，这个基本上是没有太大的异议的，两种看法的来源基本上都是来自对于mvc的理解。
对于java web应用来说，不管是B/S还是C/S，大体上都可以分成服务端和客户端两部分，只不过B/S的客户端就是公用的浏览器。
基于这种大的架构，有一种对于mvc的说法就是：
m是model，也就是和数据库相关的那些，比如实体类和、mapper.xml等，对应着三层结构的数据访问层；
v是view，也就是前台的页面或者说是客户端展示给用户看的东西，也就是展现层；
而c就是controller以及service等具体的业务逻辑，对应着三层结构的应用层。123
而对于这种说法，为什么我觉得有道理呢？是因为按照这种描述，就是和前台展示直接相关的东西都放在展现层。
*比如controller要直接和url打交道，而很多时候返回给客户端的数据也会封装成对象的形式，经常就是model；也就是说不管是controller还是model，都实打实和用户看得到的部分相关，就划为了展现层。
只不过在某些时候，就比如我们现在的项目中，为了进一步的实现松耦合，我们会创建一个command类，类似于实体model，然后用model操作数据库，用command和前台打交道，道理是一样的。
而在另一方面，我们现在项目前端使用的技术是angular js，这项技术现在也说实现了前台的mvc，有controller、service，还有数据层。
因此在这种情况下，我个人就觉得，mvc本就是一个概念，重要的是一种理解，它本身的作用只是为了实现松耦合，而不是为了mvc而mvc，未必一定要有一个唯一的答案！
欢迎有其他理解的朋友留言交流！
以下是我觉得比较好的其他理解：
来自网络的说法，是否是标准？
MVC（模型Model-视图View-控制器Controller）是一种架构模式，可以用它来创建在域对象和UI表示层对象之间的区分。
同样是架构级别的，相同的地方在于他们都有一个表现层，但是他们不同的地方在于其他的两个层。
在三层架构中没有定义Controller的概念。这是最不同的地方。而MVC也没有把业务的逻辑访问看成两个层，这是采用三层架构或MVC搭建程序最主要的区别。当然了。在三层中也提到了Model，但是三层架构中Model的概念与MVC中Model的概念是不一样的，“三层”中典型的Model层是以实体类构成的，而MVC里，则是由业务逻辑与访问数据组成的。
这是来自网络知道的说法，是否专业？
MVC和三层架构有什么区别就是MVC是最流行的三层架构中的一种框架，就是模型-视图-控制器三者分离。
MVC模式（Model–view–controller）是软件工程中的一种软件架构模式，把软件系统分为三个基本部分：模型（Model）、视图（View）和控制器（Controller）。
MVC模式最早由Trygve Reenskaug在1978年提出[1] ，是施乐帕罗奥多研究中心（Xerox
PARC）在20世纪80年代为程序语言Smalltalk发明的一种软件架构。MVC模式的目的是实现一种动态的程式设计，使后续对程序的修改和扩展简化，并且使程序某一部分的重复利用成为可能。除此之外，此模式通过对复杂度的简化，使程序结构更加直观。软件系统通过对自身基本部分分离的同时也赋予了各个基本部分应有的功能。专业人员可以通过自身的专长分组：
控制器（Controller）- 负责转发请求，对请求进行处理。 视图（View） - 界面设计人员进行图形界面设计。 模型（Model）
- 程序员编写程序应有的功能（实现算法等等）、数据库专家进行数据管理和数据库设计(可以实现具体的功能)。
来自来看日出的评论，我觉得有道理
无意中看到这个问题，我前段时间也想了很久，今天看到有点感触，不知道您怎么看，我一直其实有疑惑的(一个刚参加工作的新人)对于mvc的三层架构，设计理念是为了实现高内聚低耦合，您说得第一种三层结构，我觉得其实并没有达到这个低耦合的效果，因为在应用层处理业务时，并没有将真正的业务逻辑和数据库逻辑分离开来，仅仅将视图和逻辑分离开了，并没有达到低耦合的效果，个人这并不是真正的MVC。
个人的理解，mvc应该分为5层。
1.视图层(html/jsp/)等用户能看得到的信息，数据信息的开始和结束。
2.控制层(servlet/action),控制层不处理任何业务(包括业务逻辑和数据库逻辑)，只为控制流程，实现跳转功能，只调用service层的结果实现跳转功能，控制层的逻辑更偏向视图层，为视图层提供服务。
3.服务层(service)：专门处理业务逻辑，是控制层和DAO的中间过渡层，根据DAO层的返回结果的不同，处理不同的业务逻辑，并将结果向上返回给控制层。
4.DAO层：专门处理各种数据库逻辑，包括对数据库的CRUD，存储过程/函数各种操作，提供访问数据库的接口，DAO层更偏向于model。
5.数据模型层：专门封装数据原始模型(javabean/DTO)，本身不提供任何对数据库的操作，只提供接口供DAO层调用数据。 从上到下依次为视图层，控制层，服务层，DAO层，数据模型层。 个人理解，新人刚入门，有错误的地方希望指出共同学习。
我对来看日出的回复如下：
实际上，我个人现在的观点是，我觉得我说的两种都有道理，而你说的这一种也有道理，只看出发点是什么，能不能说通。
你的这种说法，应该是实际开发时的代码结构，后端通常有model、、service、controller，但是现在的前端，就比如我们用的angular js，实际上也分成了数据模型层、servie层、controller层、html展示层。
因此，我的理解是，网上常见的mvc解释应该是针对之前整个系统架构比较简单的情况，而现在前后端各种架构和技术都复杂起来了，可能便不能再这样简单的对应。
也就是说，我说的两种实际上对于现在的情况可能都不对了。
随着工作时间的增长，我对这个问题的看法一直在变，或许就是那句“看山是山，然后看山不是山，然后看山是山”，理解性的东西，本来就会随着个人的阅历增长而变化，今天觉得对的可能明天就觉得错了。
所以，归根结底，我觉得可以回到主题：我觉得对错不重要，重要的是能不能说通，是不是自己的理解，对也好，错也罢，能说的有理有据就够了，因为理解会变。
❾ 请问JAVA三层架构，持久层，业务层，表现层，都该怎么理解和MVC三层模型有什么
这个嘛，有一定的联系啦，也并不是完全是一样的啦，你首先把mvc理解清楚吧，M是MODEL（模型）,V是view（视图）， C是Controller（控制器），而java三层架构，持久层即是数据的持久化操作，就是数据层啦，即是数据库啦，业务层主要是业务逻辑的处理，负责表示层与数据层（持久层）的数据的传递和逻辑处理，就当很接近控制器的功能啦，就可以理解为控制器啦，表示层即是对数据的展示与用户的输入，所以呢？就是视图层啦 1. 用户看到view2. view ——————————》 controller用户操作（点击按钮等）3. controller——————》model调用model中方法3. model ——————》 controller返回数据到controller5. controller——————————》 view传数据到view，更新view6.用户看到更新后的view M——模型层，V——视图层，C——控制层，持久层——通常用于封装数据库连接、数据查询等操作，