「java里分层」java各层

今天给各位分享java里分层的知识，其中也会对java各层进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、为什么JavaWeb项目要分层
• 2、java是怎么分层的
• 3、北大青鸟java培训：分层架构的优缺点有哪些？
• 4、北大青鸟java培训：分层架构的优缺点分析？
• 5、java里分的三层到底是哪三层？

为什么JavaWeb项目要分层

首先让我们坐着时光机回到n年前的web开发。

那个时候最早都是静态的html页面，后来有了数据库，有了所谓的动态页面，

然后程序猿在编码的时候，会把所有的代码都写在页面上，包括数据库连接，包括事务控制，接收参数，各种校验，各种逻辑，各种html/js/css代码等等

怎么样？够乱吧？像一坨那什么一样，这个页面可能有成千上万行？

那么好，问题来了，回头需要修改的时候，你怎么办？

你找个东西找半天，好不容易找到了，还不敢改，怕被其他地方用了，改出连带问题。

页面一出错，定位不准到底是哪里的问题，从头到尾的挨个排查。

等等等等。

这就是大家常说的什么叫可维护性，这也是为什么越来越多的公司的规范要求不能写复杂sql。

还记得之前在东软的时候，一哥们写了一个80多行的大sql来完成一个核心的查询。

试问这个大sql天天在数据库里run，还有性能可言？

再试问谁敢改？

后来项目要改需求还是出现bug了，那个sql要改动，写sql的哥们改了好久才改好，因为时间长他也忘了，

再后来他离职了。。。

有人问，那简单sql实现不了我的功能呀，怎么办？

从数据库设计层面开始下手，要允许适当的冗余，把表弄好，就迎刃而解了，这也是数据库层面的一种解耦吧。

后来。。。

进入第二阶段，大家痛定思痛，决定要把页面和逻辑拆开，页面只是负责显示，逻辑都在后台。

这就出现了短暂的，在jsp里使用标签调用bean的用法。bean里耦合了除了页面之外的所有东西。

再后来。。。

进入了第三阶段，大家又痛定思痛，决定要拆成三部分，就是大名鼎鼎的MVC。

再再后来。。。

衍生出来了类似于struts/springmvc等等的mvc框架

---------------

JavaWeb项目的层有2个维度。

第一个维度是MVC的三层：

M：model，模型层，包括了你的业务逻辑和数据库操作，封装好给视图层使用的。

V：view，视图层，仅仅做的是展示数据，不包含业务逻辑，主要是jsp/html等等

C：controller，控制层，负责接收请求，调用模型层处理业务逻辑并返回给视图层。

第二个维度是java代码里的三层：

controller：控制层，负责接收参数/解析参数/封装参数，调用serivce，将service方法的返回值进行封装（如果需要），返回数据/返回页面，路由。

service：负责业务逻辑，事务控制在这层里做，被controller调用，以及调用dao。

dao：持久层，负责数据库交互，被service调用。

这2个维度别弄混了哟。我今天主要说的是第二个维度的层哟。

我认为，第二个维度是第一个维度的延伸，其实第二个维度再加上一个表现层就完美了，这就为什么有人说是4层架构。

---------------

前戏结束，步入正题：

有些学生朋友可能会问为什么要分层呢？我本来可以在一个地方写完的东西，非要散落在各个层中，都在一起不是挺好的吗？

开发效率高呀~

跳来跳去的我脑子都晕啦。。。

这就是为什么有人会把所有的东西都扔在一个层里，比如controller层。。。

其实我们可以在jsp上把所有的逻辑以及数据库操作,数据展示全部写在一起，耦合在一起，这样开发起来貌似更快，

但是维护性非常差，有朝一日想改一个小地方，牵一发而动全一身，隐患很高，无法快速定位问题。

因此我们需要分层。

分层了之后，你理论上改了持久层的东西，逻辑层是不用变动的。

每个Dao类是跟每个表走，Dao的每个方法里就一个个的简单sql，不包含任何业务逻辑，可以被不同的service复用和调用。

经过抽象后基本上都是通用的，因而我们在定义DAO层的时候可以将相关的方法定义完毕，

这样的好处是在对Service进行扩展的时候不需要再对DAO层进行修改，提高了程序的可扩展性。

提高了程序的可扩展性。具体什么时候做这些操作，怎么做这些操作都由Service来处理。

（就像郭德纲的相声里的一句话：“行了，你甭管了”）

而Service则不是，一个Service里可以会调用多个不同的dao，完成特定的业务逻辑，事务控制，

封装Service层的业务逻辑有利于通用的业务逻辑的独立性和重复利用性

同时，一个Service的方法也有可能被多个Controller的方法来调用。

逻辑出问题就在Service找问题，数据库，sql有问题就在Dao层找问题，

参数解析错误，跳转错误，就在Controller上找问题。

这样快速定位问题，互不干扰。

---------------

分层架构（这里会延伸到更广阔的架构）：

回头项目玩大了，怎么办？拆！！！

具体可以搜一下：maven分模块开发，怎么玩代码依赖，怎么玩微服务，怎么玩SOA，怎么玩RPC，怎么玩dubbo。

web项目发展有几个阶段啊

第一个阶段（单一应用架构）：

所有代码都耦合在一个项目里，放在一台服务器上，这种all in one的方式是有好处的。

创业初期，不用什么架构，走敏捷开发，最快速的实现需求才是王道。

你甭管我有多烂，我至少能跑起来，我至少能在外网上让你访问，让你使用。

当然了，初期的访问量很少，节省部署和运维成本才是王道呀。

听阿里的讲座，说淘宝的前期的版本用的就是一台PC机作为服务器，所有的功能耦合在一个项目里，

每次往生产环境上发版本，要上传一个600mb的包，呵呵。

第二个阶段（垂直应用架构）：

哎哟，不错哦。自己的儿子被越来越多的人访问，访问量激增，一台服务器扛不住了，

没事，我们可以玩负载均衡，玩集群。

但是！这种性能加速度其实会变得越来越小，因为你的项目是耦合在一起的。

这时，我们需要拆分项目，这里又有2个维度，按层拆，按模块拆。

将拆好的不同项目分别部署在不同的服务器上，并且再分不同的小集群。

第三个阶段（分布式服务架构）：

唉呀妈呀，访问量陡增，到这步你创业应该算成功了，开始烧投资人的钱了吧。

经过上面拆成了越来越多的模块，模块与模块交互越来越多，怎么办？

这个时候我们需要把核心的业务抽出来，作为独立的服务，慢慢发展成稳定的服务中心，

用来提升业务复用和整合。

就像阿里的大牛说过，没有淘宝的积累，天猫能那么快的出来吗？

这个时候，你的缓存，数据库，消息队列等服务都应该是分布式的。

第四个阶段（流动计算架构）

哎呀妈呀，访问量又上了一个台阶，翻了好几百倍吖，肿么办？

这个时候服务越来越多，一些容量和资源的浪费问题凸显出来，

这时我们需要一个调度中心来基于访问压力动态的管理集群容量，

提高利用率。

第五个阶段（云计算架构）

抱歉，作者正在学习中，未完待续。

java是怎么分层的

MVC模式。

Model模式层

View视图层

Controller控制器

视图(View)代表用户交互界面，对于Web应用来说，可以概括为HTML界面，但有可能为XHTML、XML和Applet。随着应用的复杂性和规模性，界面的处理也变得具有挑战性。一个应用可能有很多不同的视图，MVC设计模式对于视图的处理仅限于视图上数据的采集和处理，以及用户的请求，而不包括在视图上的业务流程的处理。业务流程的处理交予模型(Model)处理。比如一个订单的视图只接受来自模型的数据并显示给用户，以及将用户界面的输入数据和请求传递给控制和模型。

模型(Model)：就是业务流程/状态的处理以及业务规则的制定。业务流程的处理过程对其它层来说是黑箱操作，模型接受视图请求的数据，并返回最终的处理结果。业务模型的设计可以说是MVC最主要的核心。目前流行的EJB模型就是一个典型的应用例子，它从应用技术实现的角度对模型做了进一步的划分，以便充分利用现有的组件，但它不能作为应用设计模型的框架。它仅仅告诉你按这种模型设计就可以利用某些技术组件，从而减少了技术上的困难。对一个开发者来说，就可以专注于业务模型的设计。MVC设计模式告诉我们，把应用的模型按一定的规则抽取出来，抽取的层次很重要，这也是判断开发人员是否优秀的设计依据。抽象与具体不能隔得太远，也不能太近。MVC并没有提供模型的设计方法，而只告诉你应该组织管理这些模型，以便于模型的重构和提高重用性。我们可以用对象编程来做比喻，MVC定义了一个顶级类，告诉它的子类你只能做这些，但没法限制你能做这些。这点对编程的开发人员非常重要。

业务模型还有一个很重要的模型那就是数据模型。数据模型主要指实体对象的数据 保存（持续化）。比如将一张订单保存到数据库，从数据库获取订单。我们可以将这个模型单独列出，所有有关数据库的操作只限制在该模型中。

控制(Controller)可以理解为从用户接收请求, 将模型与视图匹配在一起，共同完成用户的请求。划分控制层的作用也很明显，它清楚地告诉你，它就是一个分发器，选择什么样的模型，选择什么样的视图，可以完成什么样的用户请求。控制层并不做任何的数据处理。例如，用户点击一个连接，控制层接受请求后, 并不处理业务信息，它只把用户的信息传递给模型，告诉模型做什么，选择符合要求的视图返回给用户。因此，一个模型可能对应多个视图，一个视图可能对应多个模型。

模型、视图与控制器的分离，使得一个模型可以具有多个显示视图。如果用户通过某个视图的控制器改变了模型的数据，所有其它依赖于这些数据的视图都应反映到这些变化。因此，无论何时发生了何种数据变化，控制器都会将变化通知所有的视图，导致显示的更新。这实际上是一种模型的变化-传播机制。模型、视图、控制器三者之间的关系和各自的主要功能，如图1所示。

北大青鸟java培训：分层架构的优缺点有哪些？

在进行软件开发过程中，为了能够更有效的执行系统架构，一般情况下需要进行分层结构的形式来构成。

那么在使用分层架构的过程中有哪些优缺点呢？下面电脑培训为大家具体介绍。

一、什么是分层架构分层体系结构主要是根据水平分割将软件模块划分为多个层次。

系统由多层组成，每一层由多个模块组成。

那么多少层才是合适的呢？IT培训认为，根据不同的复杂性分为不同的层次，基本的层次结构是三个层次，即表示层、域层和数据持久层。

二、分层架构的好处1、单一职责：每层只负责一个角色，责任边界清晰。

如果持久层只负责数据查询和存储，则字段级别仅负责处理业务逻辑。

2、高内聚：分层是在相同的层中放置相同的责任，并且所有业务逻辑在领域层中都是一致的。

做这个的好处是什么？江西北大青鸟设想如果业务逻辑分散在每层上，则修改功能需要修改为各层，测试业务逻辑需要测试所有层的代码，从而增加了整个软件的复杂度和测试难度。

3、易维护将面对变更且容易修正的所有对外界面放入对外界面层中，如果外部依存的界面被修改的话，只要变更该层的代码即可。

三、分层架构的缺点1、开发成本高由于多层承担着各自的任务，因此需要在多个级别上追加代码，以添加功能。

这样，开发成本就会增加。

但是，北大青鸟认为合理的能力抽象化可以提高多重性，降低开发成本。

2、可扩展性低：由于在上下层之间存在结合度，所以所有的功能变化都有可能参与多层的修正。

北大青鸟java培训：分层架构的优缺点分析？

我们在开发软件的时候，为了能够更有效的进行系统架构，一般会使用分层架构的形式来进行搭建。

下面宁夏电脑培训就一起来了解一下关于分层架构的优缺点都有哪些。

什么是分层架构?分层架构是将软件模块按照水平切分的方式分成多个层。

一个系统由多层组成，每层由多个模块组成。

那么到底分几层合适?我认为根据不同的复杂度分成不同的层次，基本的是分层架构是三层，即表现层，领域层和数据持久层。

而《领域驱动设计》EricEvans建议分四层分别是表现层，应用层、领域层和基础层，业务逻辑在领域层，基础层比持久层的范围更大，不仅可以提供持久层服务，还可以提供缓存等服务。

四层中的应用层是对三层架构中领域层进行进一步拆分。

但是无论怎么分层，业务逻辑永远在领域层。

分层架构的好处分层架构的目的是通过关注点分离来降低系统的复杂度，同时满足单一职责、高内聚、低耦合、提高可复用性和降低维护成本。

单一职责：每一层只负责一个职责，职责边界清晰，如持久层只负责数据查询和存储，领域层只负责处理业务逻辑。

高内聚：分层是把相同的职责放在同一个层中，所有业务逻辑内聚在领域层。

这样做有什么好处呢?试想一下假如业务逻辑分散在每一层，修改功能需要去各层修改，测试业务逻辑需要测试所有层的代码，这样增加了整个软件的复杂度和测试难度。

低耦合：依赖关系非常简单，上层只能依赖于下层，没有循环依赖。

可复用：某项能力可以复用给多个业务流程。

比如持久层提供按照还款状态查询信用卡的服务，既可以给申请信用卡做判断使用，也可以给展示未还款信用卡使用。

易维护：面对变更容易修改。

把所有对外接口都放在对外接口层，一旦外部依赖的接口被修改，只需要改这个层的代码即可。

以上这些既是分层的好处也是分层的原则，大家在分层时需要遵循以上原则，不恰当的分层会违背了分层架构的初衷。

分层架构的缺点分层架构也有几个缺点开发成本高：因为多层分别承担各自的职责，增加功能需要在多个层增加代码，这样难免会增加开发成本。

但是合理的能力抽象可以提高了复用性，又能降低开发成本。

性能略低：业务流需要经过多层代码的处理，性能会有所消耗。

可扩展性低：因为上下层之间存在耦合度，所有有些功能变化可能涉及到多层的修改。

java里分的三层到底是哪三层？

三层通常是指MVC设计模式，即Modle（模型）层，View（视图）层，Controller（控制器）层。模型层通常是放实体类如学生类，老师类等。视图层通常是指展示效果的一些类。控制器指控制程序流程逻辑的类。

MVC是一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑放到一个部件里面，在重构界面时，不需要重新编写业务逻辑。实现视图和逻辑的分离。

关于java里分层和java各层的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。