锁定老帖子 主题:我写的一个简单框架,感觉不错但需要改进
该帖已经被评为隐藏帖
|
|
---|---|
作者 | 正文 |
发表时间:2009-05-27
重在基础啊,继承、多态,反射,线程搞明白了就可以自己写框架了。个人认为不要拘泥于某几个框架。
|
|
返回顶楼 | |
发表时间:2009-05-27
ztbzg 写道 重在基础啊,继承、多态,反射,线程搞明白了就可以自己写框架了。个人认为不要拘泥于某几个框架。 写出来的框架如何又是另一回事了。。 其他都好说,还没看到楼主怎么弄自己的orm |
|
返回顶楼 | |
发表时间:2009-05-27
适合的就是最好的, 并在持续开发中不断地重构, 因此我对于楼主自己发明轮子持赞同赞赏态度. 没必要什么service, dao 一套套的.
|
|
返回顶楼 | |
发表时间:2009-05-27
最后修改:2009-05-27
01404421 写道 zozoh 写道 说说我的一点个人看法,LZ别介意:
1. query 如果返回 ResultSet 的话, 那么必然得让调用者关闭 Connection 吧,这样会可能造成连接泄漏 2. 针对这样的 Dao ,调用者还是的拼装大量的 SQL ,尤其是复杂查询的时候,未必让我减轻多少工作量 谢谢ZOZOH的关注,其实我也在头痛第一个问题: 1.我想给程序员提供比较灵活的一个query方法,但是这样就导致必须让程序员自己调用方法来关闭Connection ,其实也可以直接返回封装好的List<Bean>,但是这样对内存是一个很大的占用,不清楚选择哪种方案.... 2.程序员拼装SQL其实用的不多,只有在需要比较特殊的query和execute方法时需要自己拼装,其它常用的方法我这个Abstract Dao中已经使用反射完全实现,程序员只需调用就行了 可以学习jdbcTemplate,或者你直接使用spring得了。。jdbcTemplate采用了缓存的resultSet,可以不影响你关闭连接,然后提供回调方法进行查询... 没感觉lz搞的是个框架。。离框架还远着呐。。。 |
|
返回顶楼 | |
发表时间:2009-05-27
lookdd1 写道 01404421 写道 zozoh 写道 说说我的一点个人看法,LZ别介意:
1. query 如果返回 ResultSet 的话, 那么必然得让调用者关闭 Connection 吧,这样会可能造成连接泄漏 2. 针对这样的 Dao ,调用者还是的拼装大量的 SQL ,尤其是复杂查询的时候,未必让我减轻多少工作量 谢谢ZOZOH的关注,其实我也在头痛第一个问题: 1.我想给程序员提供比较灵活的一个query方法,但是这样就导致必须让程序员自己调用方法来关闭Connection ,其实也可以直接返回封装好的List<Bean>,但是这样对内存是一个很大的占用,不清楚选择哪种方案.... 2.程序员拼装SQL其实用的不多,只有在需要比较特殊的query和execute方法时需要自己拼装,其它常用的方法我这个Abstract Dao中已经使用反射完全实现,程序员只需调用就行了 可以学习jdbcTemplate,或者你直接使用spring得了。。jdbcTemplate采用了缓存的resultSet,可以不影响你关闭连接,然后提供回调方法进行查询... 没感觉lz搞的是个框架。。离框架还远着呐。。。 谢谢lookdd1指导,我是初学框架,只知道功能够我们用就行了,也不一定非要叫什么框架,而其他的成熟框架并不一定是我们需要的 |
|
返回顶楼 | |
发表时间:2009-05-27
1,Role实例应该放在一个单例的map里,每次到map里去取
2,logic层当然需要,把业务逻辑从action里独立出来,解耦 把日志/异常处理/权限检查放在Abstract Dao里,是传统的做法,不太好,不如以aop方式实现,dao只处理save/update/delete/query |
|
返回顶楼 | |
发表时间:2009-05-27
taelons 写道 1,Role实例应该放在一个单例的map里,每次到map里去取
2,logic层当然需要,把业务逻辑从action里独立出来,解耦 把日志/异常处理/权限检查放在Abstract Dao里,是传统的做法,不太好,不如以aop方式实现,dao只处理save/update/delete/query 谢谢指点,我也发现了把日志/异常这些应该从Dao中分离出来,具体方法还没有想好 Role是角色分类,每个人来操作里面的值都不一样,怎么放到Map里,taelons能不能说详细点,谢谢 |
|
返回顶楼 | |
发表时间:2009-05-27
在各位的指点下,我修改了一部分设计,见主题:我写的一个简单框架(改进版)
|
|
返回顶楼 | |