Java服务器架构.docVIP

Java服务器架构 1程序架构： 1.1现实中什么时候使用架构更好？ 架构的使用必须根据工程的实际情况来决定，一个工程能够顺利完成才是最重要的，而使用什么样的架构来进行，要因工程而异（不懂的人，你使用架构人家反而觉得你浪费了工期）架构越代码区分的越细致、工程的金额自然越高金额小工期短的工程使用最简单的方式去进行工程的制作就够了，而项目才会考虑到使用架构 1、JSP+数据库 其中，JSP主要负责页面和逻辑的全部工作，而数据库负责数据的存储。 2、JSP+Servlet（业务）+数据库 那么，第二种架构和第一种除了多使用了Servlet之外还有什么不同呢？ 在第二种架构下，我们的JSP只负责页面的呈现，而Servlet主要负责逻辑，让代码达到分离的作用，分的，它的结构就越好，可升级性就越高 3、JSP+Servlet+JAVA类+数据库 在这里，JSP主要负责页面的呈现，Servlet主要负责负责数据合法性的验证，Java类负责业务 4、JSP+Servlet+Java类+Java类+数据库 在这里，JSP主要负责页面的呈现，Servlet主要负责负责数据合法性的验证，Java类负责业务 5、JSP+Servlet+Struts+Spring+Hibernate 这是目前最流行的架构，大项目基本上都会选择这种方式公司提供的架构： 但是这个架构太大了，目前能使用的人很少人愿意使用这个架构，金额上千万到使用这样的架构 1.3程序内部的两部分架构： 两种方案： 两层架构： 数据处理层 1.3.2三层架构： 三层架构比两层架构要复杂一些，它是目前最流行的，据说它是来自于VB这一门语言的，它是程序员在使用VB时发明的所以经典三层、VB三层都说的它分为页面层业务逻辑层数据处理层C/S和B/S，而程序内部的架构主要就是上面说的两层架构和三层架构无论是C/S还是B/S都适用于我们的两层和三层架构1.3.3为什么要使用两层、三层架构： 我们知道，现实中一个工程一般一使用就是很多年，所以我们必须考虑到项目的升级性和可扩展性，比如工程本来是使用JSP使用的，现在要替换为另一种模式，那么这时候我们的很多逻辑都需要重新书写去与新的模式进行匹配，这可能就意味着我们需要重新再做一个工程，那么我们应该如何让这样的操作变得更加简单省事呢？ 所以，我们可以将做成另外一种形式我们的JSP不再参与逻辑，只负责页面的，而我们真正的逻辑都书写在JAVA类中，这样今后如果我们想要更改工程的模式只需要将新的模式跟我们的JAVA类进行对接就可以了，不需要对工程进行大改，因为这里的逻辑已经不会出现在我们的JSP或是Servlet中了，我们的JSP和Servlet现在仅仅只需要进行页面的呈现和一些数据的验证了，这样工程的升级性就 同样，如果我们将逻辑JSP和Servlet，今后就算我们不再使用JSP和Servlet来书写工程，对我们的程序员来说也不会有什么影响，因为我们只需要使用新的技术与Java类进行一个对接就可以了，这就是我们的两层结构也就是页面层绝对不能包含任何的逻辑代码而我的逻辑处理层也不能包含任何的页面的内容（request、response都不能出现），它们的交互只能是数据上的交互，而不能掺杂进对象的交互，要将它们真正的分离开来，做到就算将它们一刀切开也不会再影响到任何一方的运行，我们的类不要对页面产生任何依赖、页面也不要对我们的类产生任何依赖就可以了，否则我们就没有办法对它进行一个便捷的升级和扩展了。 两层架构示意图（以学生系统为例子）两层架构就是将视图层和业务逻辑层及数据处理层进行了分割，但是这样也会有一个问题，比如客户突然想将mySQL数据库转变为Oracle数据库，而这时，我们的两层结构数据的处理和逻辑的处理是存在于同一层的，我们工程中的语法都是支持MySQL数据库而不支持Oracle数据库的，在数据库中一条代码就能解决掉很大的问题，而更换数据库后用到很多条代码才能解决，那么我们想要更换数据库，又得再重新书写业务逻辑数据层的代码所以，数据库的灵活更换也就显得更加重要我们的业务逻辑层与数据处理层就分离开来了于是， 图3：两层架构和三层架构对比示意图 三层架构的出现，也是因为我们的数据变更太大，所以我们的SQL语句就再也不能在我们的业务层出现了，而我们的增删查改也只出现在我们的数据处理层，这里我不再需要使用这些SQL语句只需要知道这些操作的方法让数据处理就业务处理就只负责，以后我们如果数据库进行更换，就直接更换，数据管理层只需要向业务层提供数据的增删查改方法就，SQL语句，全部书写在数据层里进行操作就可以了，业务层要对数据库进行操作，只需要对数据层提供的方法进行调用，这样我们以后需要更换和升级数据库的时候，就和我们的业务逻辑层完全没有关系了 三层架构的三个层次互