当前位置: 首页>后端>正文

javaweb开发有感

? ? ? ?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中的方法实现(看了一个帖子,链接地址为:http://www.iteye.com/topic/35907,说Service层的方法也可以互相调用)。业务层中的类往往都用事务管理,因为一个业务往往就是一个事务,比如银行的转账业务,既要从一方扣钱,又要给另一方加钱,在扣钱和加钱的间隙出问题了,事务就要回滚,不然是不合情理的。

在开发过程中我发现,大家的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开发是很没技术含量的,因为有成熟的框架。这样的说法对我是挺刺激的,毕竟,自己堂堂一个本科生,心底里总还是想做点有技术含量的工作,我有个愿望,想成为一名软硬兼通的工程师,大概也是基于这样的观念吧——技术含量。

我仿佛并没有考虑自己是否感兴趣,只是觉得只要努力,便能做到。道理我也懂,先把目前的工作搞好,既然从事的是软件,就老老实实把软件先做好。别人说的话,听听是对的,但还要想一想。我觉得,能把一个庞大的系统分析设计出来,能解决这中间出现一系列问题,其实并不容易。有句话说得好,做好平凡事,你就不平凡。

最近的想法是如果觉得自己能胜任工作,那就换一个角度想一想,比如自己不依靠一些现成的东西(比如框架),也可以把自己想象成项目经理,看看自己是否有能力解决掉所有项目经理要处理的事情,如果不能,那就还是去练内功吧。

找一些有难度的事情给自己点挑战,要保证自己一直在进步,一直在成长。


https://www.xamrdz.com/backend/3vn1936603.html

相关文章: