java代码为什么要分层,java分层编译

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

java中的4层架构，为什么要将3层分层4层，这样有什么好处，4层后，每层是干什么的

分层的好处就在于代码清晰，结构分明，有利于修改和维护。增加代码的可读性。我6层的都用过。

java的某些项目为什么要采用分布式开发？什么是分布式开发？那们给解释一下！

java的某些项目为什么要采用分布式开发，分布式开发

在数据库应用程序的开发过程中，网络已走到社会的各个角落。从金融行业的银行联网、交通行业的售票系统、公安系统的全国户籍管理等等，这些企业或行业单位之间地理分布性或业务分布性，使得一个企业或行业拥有多个网络服务器，如何在这种分布式的网络环境下实现高效的数据库应用程序的开发是一个重要的问题。

分布式应用开发简单的说，是指将用户界面、控制台服务、数据库管理三个层次部署在不同的位置上。其中用户界面是客户端实现的功能，控制台服务是一个专门的服务器，数据管理是在一个专门的数据库服务器上实现的。

提示：这里的Web服务器，都是指软件（如IIS等Web服务器软件），它和Web服务器应用以及其它程序等，共同存在于服务器计算机上。

控制台CGI应用：是一个独立的控制台EXE。它在一个标准输入设备上接收客户端的请求信息，在标准输出设备上将结果返回给服务器。

分布式数据库系统已经成为信息处理学科的重要领域，正在迅速发展之中，原因是什么？

1、它可以解决组织机构分散而数据需要相互联系的问题。比如银行系统，总行与各分行处于不同的城市或城市中的各个地区，在业务上它们需要处理各自的数据，也需要彼此之间的交换和处理，这就需要分布式的系统。

2、如果一个组织机构需要增加新的相对自主的组织单位来扩充机构，则分布式数据库系统可以在对当前机构影响最小的情况下进行扩充。

3、均衡负载的需要。数据的分解采用使局部应用达到最大，这使得各处理机之间的相互干扰降到最低。负载在各处理机之间分担，可以避免临界瓶颈。

4、当现有机构中已存在几个数据库系统，而且实现全局应用的必要性增加时，就可以由这些数据库自下而上构成分布式数据库系统。

5、相等规模的分布式数据库系统在出现故障的几率上不会比集中式数据库系统低，但由于其故障的影响仅限于局部数据应用，因此就整个系统来讲它的可靠性是比较高的。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

请问java的分层思想该怎么理解？各层之间的关系是怎样？忘代码详解！高手们！救救这只迷途羔羊吧！好人

分层就是把代码按照逻辑，分成多个不同的层次。

分层的目的是让结构更清晰，代码编写的时候也更好管理。

比如三层的MVC，分为model业务层，view展示层，control控制层。

更个部分的代码相对独立，层次的关系也很明了。有的会把model层再细分。。。

代码详解就算了吧。

你了解这个还是通过项目了解的好，这种分层思想也是从实际工作中总结出来的。不是凭空想象的、。

为什么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个维度，按层拆，按模块拆。

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

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

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

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

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

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

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

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

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

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

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

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

提高利用率。

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

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