「java三层mvc」Java三层架构是哪三层

本篇文章给大家谈谈java三层mvc，以及Java三层架构是哪三层对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、什么是MVC(三层架构)
• 2、北大青鸟java培训：MVC和三层架构？
• 3、java中 MVC 三层架构
• 4、请问JAVA三层架构，持久层，业务层，表现层，都该怎么理解？和MVC三层模型有什么
• 5、Java中的mvc和三层结构究竟是什么关系

什么是MVC(三层架构)

前端跟服务端之间多了个中间层，前台先提交给中间层，由中间层去访问服务端。

JSP中，“%……%”里面的java代码是可以有一些业务逻辑的，而三层架构正是要将业务逻辑从页面中分离出来，因些不要过多的使用“%……%”，但根据实际情况，适量的添加一些是可以的。

而MVC实际上其实是一种架构模式，而不应该归入设计模式了，设计模式是在代码层面上说的：类都是什么样子的。

MVC编程模式

比如由html元素组成的网页界面，或者软件的客户端界面。MVC的好处之一在于它能为应用程序处理很多不同的视图。在视图中其实没有真正的处理发生，它只是作为一种输出数据并允许用户操作的方式。

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

以上内容参考：百度百科-mvc框架

北大青鸟java培训：MVC和三层架构？

Step1.情景概要Hello,小伙伴们,昨天跟大家分享了JAVAEE企业级应用开发中大家耳熟能详的概念-三层架构,那么有的小伙伴可能就会有疑问了，这种代码书写方式我每天写这些web项目时都是在采用该方式呢，四川IT培训发现那跟我们所接触的MVC有啥区别呢，借着这样的疑问,我们今天聊聊我们程序员们在开发时经常提到的MVC。

Step2.问题浅析在开发中，我们可能总是不经意间就将三层架构与Mvc混为一谈，殊不知它俩并不是一个概念。

下面我来为大家揭晓我所理解的一些“真相”。

  三层架构:通常意义上的三层架构就是将整个业务应用划分为：界面层（UserInterfacelayer）、业务逻辑层（BusinessLogicLayer）、数据访问层（Dataaccesslayer）。

区分层次的目的即为了“高内聚低耦合”的思想。

  MVC：全名是ModelViewController，是模型(Model)－视图(View)－控制器(Controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。

  哈哈，看过概念感觉有点晕晕的，那具体该怎么去理解它呢?Step3.回归代码  在步骤二中对于三层架构与MVC的概念性问题做了一个解释，当然对于我们程序员来说概念神马都是浮云，只有代码才是我们的钟爱，接下来我们来具体来看看通过代码怎么去理解两者区别。

同样还是借助我们昨天的用户登录场景来分析。

在没有分层的情况下，也没有MVC概念的前提下，我们想要通过服务器端给浏览器响应一个登录页面。

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三层模型有什么

这个嘛，有一定的联系啦，也并不是完全是一样的啦，你首先把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——控制层，持久层——通常用于封装数据库连接、数据查询等操作，

Java中的mvc和三层结构究竟是什么关系

一件事，要知其然往往很简单，要知其所以然通常不是那么容易，就如最近重新巩固spring的过程中，就觉得还有许多问题其实并不是十分明了。 

屈指一算，手头上做过的正式项目也有了四五六七个了，不管用的数据库和其他一些细节上的技术如何，总的来说大的框架结构都是差不多的。 

说白了，也就是mvc和三层结构。 

而mvc和三层结构究竟是什么关系，我曾在面试的过程中被人问过几次，也曾仔细的想过、查过这个问题，但是直到此时，我也还是不能完全确定。

只不过随着时间的积累，随着技术的沉淀，随着视野的拓宽，我大体上认同了两种说法，不管别人怎么看，我个人是觉得两种说法都有道理，欢迎对这个问题有不同看法的朋友一起讨论。 

三层结构是什么，是展现层、应用层、数据访问层，这个基本上是没有太大的异议的，两种看法的来源基本上都是来自对于mvc的理解。 

对于java web应用来说，不管是B/S还是C/S，大体上都可以分成服务端和客户端两部分，只不过B/S的客户端就是公用的浏览器。

基于这种大的架构，有一种对于mvc的说法就是：

m是model，也就是和数据库相关的那些，比如实体类和dao、mapper.xml等，对应着三层结构的数据访问层；

v是view，也就是前台的页面或者说是客户端展示给用户看的东西，也就是展现层；

而c就是controller以及service等具体的业务逻辑，对应着三层结构的应用层。123

这种说法我觉得应该是为了对应而对应，就是要把mvc和三层结构的关系一一对应起来，因此也差不多就是一个对应一个。 

或许是经验还不够多的缘故，或许本来就是这样子，反正我是觉得这种说法正确，或者更确切的说，这是大的mvc。

那么还有一种说法可能就不是像上边这样一一对应了，大体上的说法是这样的：

我们通常所说的mvc实际上只是对应了三层结构中的展现层，也就是view而已，然后v是客户端，m是实体，c是controller。

至于三层结构中的应用层和数据访问层则是分别对应了后台代码中的service和dao。12

而对于这种说法，为什么我觉得有道理呢？是因为按照这种描述，就是和前台展示直接相关的东西都放在展现层。 

*比如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、dao、service、controller，但是现在的前端，就比如我们用的angular js，实际上也分成了数据模型层、servie层、controller层、html展示层。 

因此，我的理解是，网上常见的mvc解释应该是针对之前整个系统架构比较简单的情况，而现在前后端各种架构和技术都复杂起来了，可能便不能再这样简单的对应。 

也就是说，我说的两种实际上对于现在的情况可能都不对了。 

随着工作时间的增长，我对这个问题的看法一直在变，或许就是那句“看山是山，然后看山不是山，然后看山是山”，理解性的东西，本来就会随着个人的阅历增长而变化，今天觉得对的可能明天就觉得错了。 

所以，归根结底，我觉得可以回到主题：我觉得对错不重要，重要的是能不能说通，是不是自己的理解，对也好，错也罢，能说的有理有据就够了，因为理解会变。

java三层mvc的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于Java三层架构是哪三层、java三层mvc的信息别忘了在本站进行查找喔。