JDBC中Dao层数据访问的逐步优化与总结
2015-02-17 00:59
162 查看
仅为不断进取后的自我总结并加深理解和初学码农间交流
大神请自爱!
学习的时候总会有很多心得,某些大神总是喜欢自己一个人闷在心中。让想学的菜鸟一直望其项背。没有交流就没有收获,没有对比就没进取,求大神指教,不要再自个儿修炼了。
当我们用Dao层访问数据库的时候,难免有写增删查改的时候有重复代码并且比较死,不够灵活,当表中的属性很多很多的时
候,更加不方便于我们访问。在没有使用框架之前,开始学习的时候第一次写的时候我也是这样的,以findbyId为例子:
代码图:
![](http://b279.photo.store.qq.com/psb?/V14KkUKv0tLVWO/igBCBVyZahDHGUpioRIOBK0W6xguXotHt7E2jwhhOL4!/b/dHc6UqZTCAAA&ek=1&kp=1&pt=0&bo=5AIjAgAAAAADAOI!&su=090949937&sce=0-12-12&rf=2-9)
第一步优化,很简单。。。
将公共代码提取,如上form.setALL 提取此类中一个静态的方法中 static formMapping()
![](http://b278.photo.store.qq.com/psb?/V14KkUKv0tLVWO/uQrVlzpG1cN5*TKlOxCEjdOcSYPmO96RhzGWJO604xA!/b/dCo7vqUcCAAA&ek=1&kp=1&pt=0&bo=oANsAAAAAAADAOo!&su=073895137&sce=0-12-12&rf=2-9)
如此改进之后,其实我们的增删改查操作还是需要在每个DaoImpl中实现,这样的工作还是有些累赘。其实发现,增删改查操作的代码如此类似,只是有三个地方不一样:1.String型的SQL代码不一样 2.还有对于?(问号)的赋值不一样 3.有时需要返回的结果集的映射到bean中也是不一样的(返回结果集封装到Bean中,如返回一个User) 于是第二次优化如图:
![](http://b277.photo.store.qq.com/psb?/V14KkUKv0tLVWO/qWlXK.jOuwA0MyPY0ScJFZ2TxcIgTMenh*urQ7AXpHY!/b/dLIYIaWTIQAA&ek=1&kp=1&pt=0&bo=qwM7AgAAAAADALQ!&su=0103323665&sce=0-12-12&rf=2-9)
为了解决以上三点,创建一个抽象类AbstractDao 在其中写好和具体实现类差不多的非抽象的增删查改的公用方法,将参数改为String型的SQL(select username from User where id=?等)的参数和对问号赋值时的参数。此时对问好赋值的参数就为一个Object[]的对象数组,而不是之前的具体memoid或者替他的什么,这样就可以灵活应对各种类型的参数了。
我们在抽象类中,每个方法中都是同样的代码:
![](http://b277.photo.store.qq.com/psb?/V14KkUKv0tLVWO/8qDnFW4xPQ3Z2lhJ.wvs1jgEbl1uKxezlXImoGMtVl8!/b/dEJ0HKUyIAAA&ek=1&kp=1&pt=0&bo=7gItAgAAAAADAOY!&su=079903537&sce=0-12-12&rf=2-9)
重点就是object =rowMapping() 哪个类需要调用此findUser方法时,就需要重写rowMapping行集映射的方法,将返回的数据封装到Bean中。这行代码还体现了java中一个的特性:多态。理解了之后更让人理解到多态的好处。其实这里就包含了一种java23种设计模式中的模板设计模式,用一个抽象类当模板,子类继承调用模板中的方法。
优化到这一步,其实代码已经比第一次高效多了。
但是,问题很快也就暴露出来了。。。》》》》
抽象方法rowMapping只写了一个,实现抽象方法肯定需要具体的子类来实现,因为子类才知道怎么做,如果子类需要调用findUserById,findUsername等两个及以上的操作,需要实现的rowMapping肯定不同,一个返回一个User的信息,一个返回String型的Username,但实现rowMapping也只能实现一个。所以这样的问题还需要解决。。。。。》》》
接下来是第三步优化,既然抽象类不能解决,接口总可以吧。定义一个接口RowMapper,只有rowMapping一个抽象方法,为了不让自己犯晕,方法名为:rowMapper() :
![](http://b279.photo.store.qq.com/psb?/V14KkUKv0tLVWO/hLbjkZol0Ak.9hcO8Eo4i7U5jI*ypLCF1L9NEpecWzA!/b/dD9BWKa5CAAA&ek=1&kp=1&pt=0&bo=dQIkAQAAAAADAHc!&su=0181672641&sce=0-12-12&rf=2-9)
在DaoImpl实现的时候,不再继承AbstractDao,抛弃第二次优化的结果,开始学的时候还很郁闷,花了时间弄懂模板设计模式之后,却不合适,需要再改,不过很有帮助的。
我们不再调用父类AbstractDao的增删查改方法,抛弃抽象类不使用,而是重新写一个类叫做MyDaoTemplate 此类中的增删改查的代码和AbstractDao中代码几乎一样,只是去掉抽象方法,并在增删改查的参数上增加一个RowMapper接口。将实现RowMapper的接口的类也传进去,让MyDaoTemplate的方法不止有String型的SQL,对?号赋值的参数数组,还有实现结果集映射抽象类RowMapper的具体实现类。
![](http://b279.photo.store.qq.com/psb?/V14KkUKv0tLVWO/FXdfNYuEjrgJeq4HpS*9*k15.gNDAOXU958ST87Vec0!/b/dIkyT6bpBwAA&ek=1&kp=1&pt=0&bo=sQOHAQAAAAADABE!&su=0104084833&sce=0-12-12&rf=2-9)
用接口的方式传入具体的结果集映射方法的类也叫做策略设计模式,应对不同的操作用不同的方法,对于策略模式的使用还太少,自己需要更多深入学习。
![](http://b278.photo.store.qq.com/psb?/V14KkUKv0tLVWO/s1Wah5L363NvaoDhzTifla188ysBgBqIdhlatWFRNDA!/b/dBkHuKV5BwAA&ek=1&kp=1&pt=0&bo=OwM5AgAAAAADACY!&su=0119361441&sce=0-12-12&rf=2-9)
这三步的优化已经大大减少了码农们的工作量。以后如果需要一个Dao实现的时候直接继承AbstractDao,和实现RowMapper的结果集映射方法即可。再也不用一个一个增删改查的写了,算算多少行吧! ~~~~在实现接口RowMapper的时候,可以使用内部内的方法:
![](http://b277.photo.store.qq.com/psb?/V14KkUKv0tLVWO/Bxe*aYe*u3.3enjefcuAABNfPcPONhtin8cfJgifR84!/b/dPzzIKVQIgAA&ek=1&kp=1&pt=0&bo=CQNXAQAAAAADAHk!&su=0237646513&sce=0-12-12&rf=2-9)
熟悉内部类的同学的同学,一看就懂了,这些都是java的经典啊。
以上优化包含了接口,抽象类,多态,继承,封装,模板设计模式 ,策略设计模式 。设计模式还有很多,具体应用时的学习才是最深刻的。
当我们使用Spring框架中的Template工具类的RowMapper方法的时候,Spring框架也是对JDBC API进行如上第三步优化的封装,对自己代码如此优化之后,面对Spring 框架的部分使用也更加明白了。。。
此篇总结之后更加对框架产生兴趣了。
大神请自爱!
学习的时候总会有很多心得,某些大神总是喜欢自己一个人闷在心中。让想学的菜鸟一直望其项背。没有交流就没有收获,没有对比就没进取,求大神指教,不要再自个儿修炼了。
当我们用Dao层访问数据库的时候,难免有写增删查改的时候有重复代码并且比较死,不够灵活,当表中的属性很多很多的时
候,更加不方便于我们访问。在没有使用框架之前,开始学习的时候第一次写的时候我也是这样的,以findbyId为例子:
代码图:
第一步优化,很简单。。。
将公共代码提取,如上form.setALL 提取此类中一个静态的方法中 static formMapping()
如此改进之后,其实我们的增删改查操作还是需要在每个DaoImpl中实现,这样的工作还是有些累赘。其实发现,增删改查操作的代码如此类似,只是有三个地方不一样:1.String型的SQL代码不一样 2.还有对于?(问号)的赋值不一样 3.有时需要返回的结果集的映射到bean中也是不一样的(返回结果集封装到Bean中,如返回一个User) 于是第二次优化如图:
为了解决以上三点,创建一个抽象类AbstractDao 在其中写好和具体实现类差不多的非抽象的增删查改的公用方法,将参数改为String型的SQL(select username from User where id=?等)的参数和对问号赋值时的参数。此时对问好赋值的参数就为一个Object[]的对象数组,而不是之前的具体memoid或者替他的什么,这样就可以灵活应对各种类型的参数了。
我们在抽象类中,每个方法中都是同样的代码:
重点就是object =rowMapping() 哪个类需要调用此findUser方法时,就需要重写rowMapping行集映射的方法,将返回的数据封装到Bean中。这行代码还体现了java中一个的特性:多态。理解了之后更让人理解到多态的好处。其实这里就包含了一种java23种设计模式中的模板设计模式,用一个抽象类当模板,子类继承调用模板中的方法。
优化到这一步,其实代码已经比第一次高效多了。
但是,问题很快也就暴露出来了。。。》》》》
抽象方法rowMapping只写了一个,实现抽象方法肯定需要具体的子类来实现,因为子类才知道怎么做,如果子类需要调用findUserById,findUsername等两个及以上的操作,需要实现的rowMapping肯定不同,一个返回一个User的信息,一个返回String型的Username,但实现rowMapping也只能实现一个。所以这样的问题还需要解决。。。。。》》》
接下来是第三步优化,既然抽象类不能解决,接口总可以吧。定义一个接口RowMapper,只有rowMapping一个抽象方法,为了不让自己犯晕,方法名为:rowMapper() :
在DaoImpl实现的时候,不再继承AbstractDao,抛弃第二次优化的结果,开始学的时候还很郁闷,花了时间弄懂模板设计模式之后,却不合适,需要再改,不过很有帮助的。
我们不再调用父类AbstractDao的增删查改方法,抛弃抽象类不使用,而是重新写一个类叫做MyDaoTemplate 此类中的增删改查的代码和AbstractDao中代码几乎一样,只是去掉抽象方法,并在增删改查的参数上增加一个RowMapper接口。将实现RowMapper的接口的类也传进去,让MyDaoTemplate的方法不止有String型的SQL,对?号赋值的参数数组,还有实现结果集映射抽象类RowMapper的具体实现类。
用接口的方式传入具体的结果集映射方法的类也叫做策略设计模式,应对不同的操作用不同的方法,对于策略模式的使用还太少,自己需要更多深入学习。
这三步的优化已经大大减少了码农们的工作量。以后如果需要一个Dao实现的时候直接继承AbstractDao,和实现RowMapper的结果集映射方法即可。再也不用一个一个增删改查的写了,算算多少行吧! ~~~~在实现接口RowMapper的时候,可以使用内部内的方法:
熟悉内部类的同学的同学,一看就懂了,这些都是java的经典啊。
以上优化包含了接口,抽象类,多态,继承,封装,模板设计模式 ,策略设计模式 。设计模式还有很多,具体应用时的学习才是最深刻的。
当我们使用Spring框架中的Template工具类的RowMapper方法的时候,Spring框架也是对JDBC API进行如上第三步优化的封装,对自己代码如此优化之后,面对Spring 框架的部分使用也更加明白了。。。
此篇总结之后更加对框架产生兴趣了。
相关文章推荐
- SEO网站内容建设,用户维护,主动访问用户数据体验优化
- 使用JDBC访问Hive表中的数据
- JDBC优化策略总结
- JavaWeb学习总结(三十五)——使用JDBC处理Oracle大数据
- 用Mybatis JDBC访问 Oracle的XMLType数据类型
- javaweb学习总结(三十四)——使用JDBC处理MySQL大数据
- Mysql学习总结(13)——使用JDBC处理MySQL大数据
- javaweb学习总结(三十四)——使用JDBC处理MySQL大数据
- JDBC优化策略总结
- JavaWeb学习总结(三十五)——使用JDBC处理Oracle大数据
- IO流_数据操作流、内存操作流、打印流、标准输入输出流、随机访问流、合并流、序列化流、Properties、总结
- 通过httpd.conf来优化大数据访问 - sever 2008 Apache优化配置
- Android学习总结二:五大布局、Android测试、数据存储访问(TextUtils)、Map的使用
- 第十一章 用jdbc访问大段文本数据
- 十步优化SQL Server中的数据访问
- 使用jdbc的方式访问kylin cube的数据
- 大数据量高并发访问的数据库优化方法(一)
- sqlite大量数据插入优化总结
- 优化JDBC中读取大数据字段,提高并发能力
- 优化-hive大数据倾斜总结