java web 开发入门心得.docVIP

从事Java Web开发这一段时间来，对Java 面向对象的思想和MVC开发模式可以说已经熟悉了。我当前参与的项目使用的框架是Spring、SpringMVC、Hibernate。作为刚刚参加工作的入门者，我下面谈自己的几点心得，还恳请前辈指正。 想必流行的做法都是把后台部分的代码分为entity（或domain）、dao、service、web几个层吧。 实体类 实体类就是对现实世界事物的建模，往往正是跟现实中的“实体”相对应，但也有些不是，只是为了将数据封装起来便于传输和表现（这一点，在做客户端软件时尤其如此，毕竟内存是相当有限的，拉出的数据最好全部用于表现，多余就意味着浪费内存）。 我有个观点：连接处是难点。Java代码需要连接的有两个：跟前台的页面，即视图相连接，这个靠web层；另外，就是跟数据库相连接，这个靠的是entity层。而这两个层相比，实体类又是更重要的，它就像是一幢大楼的地基。对实体类的设计，我感觉是一个项目的关键。要想设计好实体类，简单的说，需要远见，具体地说，需要不仅仅理清项目业务逻辑，还需要有较丰富的开发经验。因为理清业务逻辑，可能只是能穷举出所需要的实体以及它们直观的属性，但有时那些实体还需要拆分合并（以前参与过一个求职招聘网的项目，在建表时是把求职和招聘信息分开建的表，但到后来发现，在用户登录后需要呈现的是所有的信息，这下带来了代码的不小改动），并且有些属性虽然不那么直观，但却是有必要的，常见的就是一些flag、status之类的属性，这就需要在设计时就最好能预见到，不然在开发过程经常修改数据库中的表结构，也会开发进度。 综上，俗话说得好，磨刀不误砍柴工，实体类设计好了，往上走，将势如破竹。 另外，公司的做法是在实体类中建一个BaseObject作为一个项目中所有实体类的父类，定义几个都要用到的成员变量，如id,version，createTime。这样做，一方面减少了重复的代码，另一方面，在设计后续的BaseDao时也很方便。 数据访问对象DAO dao中的方法就是对数据库中的数据进行“单纯”的增删改查（之所以说单纯，就是因为它并没不牵涉业务），其中较复杂多变的是查找，这一点和sql语句是对应的。 对于DAO层，我们通常的做法也是创建一个父类，即BaseDao, ?并且使用Java 的泛型将BaseObject作为它要操作的数据类型，这样，在不同实体类对应的DAO去继承BaseDao时，就可以用各自的实体去替换BaseOject了（假如entity层没有采用继承BaseObject的模式，那么可以用在BaseDao中可以用Object作占位符）。 这个BaseDao还可以继承框架中已有的Dao,如HibernateDaoSupport，当然也可以自己写。 在做求职招聘网时，我们就是自己写的，形如：public class BaseDaoT, PK extends Serializable ，特别注意：该类不由Spring管理。这里边有两个难点：①如何获取Hibernate中的session对象？可以采用注释注入SessionFactory，通过调用它的getCurrentSession方法获取Session对象。②在编写查询方法时需要用到继承BaseDao的dao类所对应的实体类的类型，如何动态地获取呢？比如当UserDao继承BaseDao时，在BaseDao中如何动态地获知相应的实体类是User类型呢？这里边用到了反射和构造方法，由于子类在创建时会驱动BaseDao的创建，所以在BaseDao中的构造方法中使用this关键字，和反射中的方法获取子类泛型参数中第一个参数的类型，即为所需的entityClass 业务逻辑层Service层 业务逻辑层的方法就是对信息进行加工处理用的，业务逻辑层，顾名思义，就是根据业务对数据进行处理，主要通过调用dao中的方法实现（看了一个帖子，链接地址为：/topic/35907，说Service层的方法也可以互相调用）。业务层中的类往往都用事务管理，因为一个业务往往就是一个事务，比如银行的转账业务，既要从一方扣钱，又要给另一方加钱，在扣钱和加钱的间隙出问题了，事务就要回滚，不然是不合情理的。 在开发过程中我发现，大家的service层的方法，都和dao层差不多，甚至名字很多都一样，反倒是把真正的业务处理都放在了web层。这样做，我认为是很不科学的，web层是没有事务控制的，一旦发生异常，就可能产生脏数据。因而还是应该把业务放在本来属于它的位置上来。 发布层Web层 这又是一个连接处，它联系的是http请求/响应和Java模型，是开发中的关键点。我现在的做法通常是在有了实体类以后，从web层着手向下开发，比较喜欢点击那个不存在的方法提示出的“creat meth