java常见代码分层 java代码分析

为什么JavaWeb项目要分层

首先让我们坐着时光机回到n年前java常见代码分层的web开发。

那个时候最早都是静态的html页面java常见代码分层，后来有了数据库，有了所谓的动态页面，

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

怎么样java常见代码分层？够乱吧？像一坨那什么一样，这个页面可能有成千上万行？

那么好，问题来了，回头需要修改的时候，java常见代码分层你怎么办？

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

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

等等等等。

这就是大家常说的什么叫可维护性，这也是为什么越来越多的公司的规范要求不能写复杂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个维度，按层拆，按模块拆。

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

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

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

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

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

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

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

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

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

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

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

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

提高利用率。

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

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

相关问答

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

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

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

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

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

代码详解就算了吧。

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

Q2: java分层

com.action一般你的网站是action.com才这样命名的

dao一般是存放和数据库打交道的接口

daoImpl一般是放dao里面那些接口的实现的

没有统一的模板，不同项目，不同架构师出来的可能都不一样。

Q3: java是怎么分层的

MVC模式。

Model模式层

View视图层

Controller控制器

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

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

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

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

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

Q4: java web 怎么用代码表示分层

表现层

jsp：页面渲染

servlet：接收用户数据（）调用业务，接收业务传来的数据，页面跳转，传递数据。

业务层

service：接受servlet传入数据，进行业务规则处理，调用dao，接受dao返回的数据，向servlet返回数据。

持久化层

dao：接受业务传入数据，进行对数据库进行增删改查，得到的数据向业务层返回。

Q5: 求解释java分层开发有哪些层次

一般java都是三层架构 数据访问层（dao）、 业务逻辑层（biz 或者services） 、界面层（ui）。

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