我写的一个简单框架，感觉不错但需要改进

最近公司需要做一个系统，一直来感觉使用Hibernate太麻烦，为了使用很少的功能而要去掌握那么大的东西，所以自己写了一个ORM类似的东西（以后另发帖贴代码分享），现在先把自己的框架贴出来，不知道自己做的轮子到底怎么样，而且对权限这部分没有做过，如下图：

开发情况：

 1.每个人维护相对独立的几张表，所以自己写自己的Bean和Dao

解释说明：

Bean-----规定了一些Dao需要的方法

Abstract Dao封装了权限检查和日志、异常记录

Role---角色接口

Abstract Action统一封装日志和异常

 

编程人员使用说明：

1.每个人自己写的Action必须继承自NoUserAction或者WithUserAction

2.自己写Logic层，调用自己写的Dao和Bean（必须继承Abstract Dao和Abstract ComBean）

3.自己写的Dao必须继承Abstract　Dao（其中封装了常用的save update delete query等方法）

4.自己写的Bean必须继承ComBean（其中封装了一些要用到的方法）

现在存在的问题：

1.每个人自己的Action中要操作数据库必须要传入Role接口下的对象，如图：DemoAction要操作必须传入WithUserAction对象，

   这样每个Action中都必须New一个Role对象，是不是对性能造成影响

2.Logic（业务）层感觉可以不要...搞不清....

说明：我去年才毕业，没有多少开发经验，只是感觉这样能加快开发速度而且统一管理权限、日志、异常处理等，请大家多提意见！！

 

在各位的指点下，我修改了一部分设计，见主题：我写的一个简单框架(改进版)

 

评论

27 楼 01404421 2009-05-27  

<p>在各位的指点下，我修改了一部分设计，见<a href="../../../../../topic/397528">主题：我写的一个简单框架(改进版)</a></p>
<p> </p>

26 楼 01404421 2009-05-27  

taelons 写道

1,Role实例应该放在一个单例的map里,每次到map里去取
2,logic层当然需要,把业务逻辑从action里独立出来,解耦

把日志/异常处理/权限检查放在Abstract Dao里,是传统的做法,不太好,不如以aop方式实现,dao只处理save/update/delete/query

谢谢指点，我也发现了把日志/异常这些应该从Dao中分离出来，具体方法还没有想好
Role是角色分类，每个人来操作里面的值都不一样，怎么放到Map里，taelons能不能说详细点，谢谢

25 楼 taelons 2009-05-27  

1,Role实例应该放在一个单例的map里,每次到map里去取
2,logic层当然需要,把业务逻辑从action里独立出来,解耦

把日志/异常处理/权限检查放在Abstract Dao里,是传统的做法,不太好,不如以aop方式实现,dao只处理save/update/delete/query

24 楼 01404421 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指导，我是初学框架，只知道功能够我们用就行了，也不一定非要叫什么框架，而其他的成熟框架并不一定是我们需要的

23 楼 lookdd1 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搞的是个框架。。离框架还远着呐。。。

22 楼 srdrm 2009-05-27  

适合的就是最好的, 并在持续开发中不断地重构, 因此我对于楼主自己发明轮子持赞同赞赏态度. 没必要什么service, dao 一套套的.

21 楼 mccxj 2009-05-27  

ztbzg 写道

重在基础啊，继承、多态，反射，线程搞明白了就可以自己写框架了。个人认为不要拘泥于某几个框架。

写出来的框架如何又是另一回事了。。

其他都好说，还没看到楼主怎么弄自己的orm

20 楼 ztbzg 2009-05-27  

重在基础啊，继承、多态，反射，线程搞明白了就可以自己写框架了。个人认为不要拘泥于某几个框架。

19 楼 01404421 2009-05-27  

zozoh 写道

01404421 写道

whaosoft 写道

orm那块儿在哪了呀 木找到

我的Abstract Dao类似与ORM，呵呵，仅仅只是类似...
希望给程序员们提供的功能类似与ORM
明天我把代码贴上来让大家指点

LZ 可以参看一下 Nutz 的 Dao 接口，和你要求的很像，不过，它不要求程序员继承，直接使用就好了，查询，关联等功能也更强大。这里是它的主页

看了，确实不错，值得学习学习，呵呵

18 楼 ztbzg 2009-05-27  

風一樣的男子 写道

楼主挺牛X的嘛，我也去年毕业，可一名名堂都没混出来

LZ去年毕业在一传统行业干了半年，后来就自己干，很牛X，学习能力超强。我和他在一起干。

17 楼 風一樣的男子 2009-05-27  

楼主挺牛X的嘛，我也去年毕业，可一名名堂都没混出来

16 楼 zozoh 2009-05-27  

01404421 写道

whaosoft 写道

orm那块儿在哪了呀 木找到

我的Abstract Dao类似与ORM，呵呵，仅仅只是类似...
希望给程序员们提供的功能类似与ORM
明天我把代码贴上来让大家指点

LZ 可以参看一下 Nutz 的 Dao 接口，和你要求的很像，不过，它不要求程序员继承，直接使用就好了，查询，关联等功能也更强大。这里是它的主页

15 楼 cloud21 2009-05-27  

我也写过同样的东西，建议你有时间去我的blog看看。

14 楼 01404421 2009-05-26  

whaosoft 写道

orm那块儿在哪了呀 木找到

我的Abstract Dao类似与ORM，呵呵，仅仅只是类似...
希望给程序员们提供的功能类似与ORM
明天我把代码贴上来让大家指点

13 楼 01404421 2009-05-26  

zozoh 写道

01404421 写道

我刚想到，如果是多表查询就不能用List<Bean>来返回了.....麻烦啊，真头大！！！！

用 View

恍然大悟......！  

12 楼 whaosoft 2009-05-26  

orm那块儿在哪了呀 木找到

11 楼 zozoh 2009-05-26  

01404421 写道

我刚想到，如果是多表查询就不能用List<Bean>来返回了.....麻烦啊，真头大！！！！

用 View

10 楼 01404421 2009-05-26  

zozoh 写道

01404421 写道

zozoh 写道

说说我的一点个人看法，LZ别介意：

1. query 如果返回 ResultSet 的话， 那么必然得让调用者关闭 Connection 吧，这样会可能造成连接泄漏
2. 针对这样的 Dao ，调用者还是的拼装大量的 SQL ，尤其是复杂查询的时候，未必让我减轻多少工作量

谢谢ZOZOH的关注，其实我也在头痛第一个问题：
1.我想给程序员提供比较灵活的一个query方法，但是这样就导致必须让程序员自己调用方法来关闭Connection ，其实也可以直接返回封装好的List<Bean>，但是这样对内存是一个很大的占用，不清楚选择哪种方案....
2.程序员拼装SQL其实用的不多，只有在需要比较特殊的query和execute方法时需要自己拼装，其它常用的方法我这个Abstract Dao中已经使用反射完全实现，程序员只需调用就行了

如果我是你的调用者，我拿到了你给我的 ResultSet，我也需要持有在内存里啊，只不过是你替我放到内存里，还是我自己放。并且实际上 ResultSet 本来就在内存里，他的 fetchSize 属性声明了要缓存多少记录。

如果数据量大，肯定是要分页的，数据量小，一次都到内存里是应该的，所以应该用 List<Bean> 的方式

我刚想到，如果是多表查询就不能用List<Bean>来返回了.....麻烦啊，真头大！！！！

9 楼 zozoh 2009-05-26  

01404421 写道

zozoh 写道

说说我的一点个人看法，LZ别介意：

1. query 如果返回 ResultSet 的话， 那么必然得让调用者关闭 Connection 吧，这样会可能造成连接泄漏
2. 针对这样的 Dao ，调用者还是的拼装大量的 SQL ，尤其是复杂查询的时候，未必让我减轻多少工作量

谢谢ZOZOH的关注，其实我也在头痛第一个问题：
1.我想给程序员提供比较灵活的一个query方法，但是这样就导致必须让程序员自己调用方法来关闭Connection ，其实也可以直接返回封装好的List<Bean>，但是这样对内存是一个很大的占用，不清楚选择哪种方案....
2.程序员拼装SQL其实用的不多，只有在需要比较特殊的query和execute方法时需要自己拼装，其它常用的方法我这个Abstract Dao中已经使用反射完全实现，程序员只需调用就行了

如果我是你的调用者，我拿到了你给我的 ResultSet，我也需要持有在内存里啊，只不过是你替我放到内存里，还是我自己放。并且实际上 ResultSet 本来就在内存里，他的 fetchSize 属性声明了要缓存多少记录。

如果数据量大，肯定是要分页的，数据量小，一次都到内存里是应该的，所以应该用 List<Bean> 的方式

8 楼 java_283066589 2009-05-26  

AOP的拦截器，自动关闭连接，或许可以解决自己调用方法来关闭Connection的问题