java web 开发入门心得
操作方法
- 01
从事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 BaseDao<T, PK extends Serializable> ，特别注意：该类不由Spring管理。这里边有两个难点：①如何获取Hibernate中的session对象？可以采用注释注入SessionFactory，通过调用它的getCurrentSession方法获取Session对象。②在编写查询方法时需要用到继承BaseDao的dao类所对应的实体类的类型，如何动态地获取呢？比如当UserDao继承BaseDao时，在BaseDao中如何动态地获知相应的实体类是User类型呢？这里边用到了反射和构造方法，由于子类在创建时会驱动BaseDao的创建，所以在BaseDao中的构造方法中使用this关键字，和反射中的方法获取子类泛型参数中第一个参数的类型，即为所需的entityClass。 业务逻辑层Service层 业务逻辑层的方法就是对信息进行加工处理用的，业务逻辑层，顾名思义，就是根据业务对数据进行处理，主要通过调用dao中的方法实现。业务层中的类往往都用事务管理，因为一个业务往往就是一个事务，比如银行的转账业务，既要从一方扣钱，又要给另一方加钱，在扣钱和加钱的间隙出问题了，事务就要回滚，不然是不合情理的。 在开发过程中我发现，大家的service层的方法，都和dao层差不多，甚至名字很多都一样，反倒是把真正的业务处理都放在了web层。这样做，我认为是很不科学的，web层是没有事务控制的，一旦发生异常，就可能产生脏数据。因而还是应该把业务放在本来属于它的位置上来。 发布层Web层 这又是一个连接处，它联系的是http请求/响应和Java模型，是开发中的关键点。我现在的做法通常是在有了实体类以后，从web层着手向下开发，比较喜欢点击那个不存在的方法提示出的“creat method in xxxService/xxxDao”了，这样开发非常有动力，好像打一场围歼战，最后把敌人都消灭在了Dao层。 web层通常是要调用Service中的方法完成的，它起到的作用是就是调度。与Service相比，web层该是瘦子，Service该是胖子。我的一点心得是：在web层中的一个方法中不宜调用多个涉及到更新数据的Service，但可以调用多个只进行数据查询的Service方法。这样做，我想着也是怕发生异常时，同一个方法中某个事务已经提交，而另外一个事务却没有提交的情况出现。但是，如果确实在Service层中按照业务定义了方法，这种情况按说也不会出现， 其他想法 有一种声音：说目前的Java Web开发是很没技术含量的，因为有成熟的框架。这样的说法对我是挺刺激的，毕竟，自己堂堂一个本科生，心底里总还是想做点有技术含量的工作，我有个愿望，想成为一名软硬兼通的工程师，大概也是基于这样的观念吧——技术含量。 我仿佛并没有考虑自己是否感兴趣，只是觉得只要努力，便能做到。道理我也懂，先把目前的工作搞好，既然从事的是软件，就老老实实把软件先做好。别人说的话，听听是对的，但还要想一想。我觉得，能把一个庞大的系统分析设计出来，能解决这中间出现一系列问题，其实并不容易。有句话说得好，做好平凡事，你就不平凡。 最近的想法是如果觉得自己能胜任工作，那就换一个角度想一想，比如自己不依靠一些现成的东西（比如框架），也可以把自己想象成项目经理，看看自己是否有能力解决掉所有项目经理要处理的事情，如果不能，那就还是去练内功吧。 找一些有难度的事情给自己点挑战，要保证自己一直在进步，一直在成长。