Java程序架构

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