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

最近公司需要做一个系统，一直来感觉使用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（业务）层感觉可以不要...搞不清....

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

 

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

 

评论

7 楼 01404421 2009-05-26  

zozoh 写道

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

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

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

6 楼 zozoh 2009-05-26  

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

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

5 楼 01404421 2009-05-26  

zozoh 写道

我觉得你的思路挺清楚的，这样的结构也挺清晰的。
New 一个对象的消耗，在 Java 中可以忽略不计，你大可放心。

这个框架应该很贴合你们的业务，我觉得如果弄出来，肯定很不错。关键是，你打算怎么实现你的 AbstractDao 呢？ 能贴一下 AbstractDao 的接口函数定义吗？

封装了一些常用的数据库操作方法，尽量让程序员少写SQL代码，而且这样可以容易控制权限
protected final int save(Bean bean) ；
/*
	 * 修改方法 id为要修改的数据ID，paraName为属性名称,paraValue为新值
	 * 返回1为操作成功 0为没有执行操作 -1为出异常了
	 */
	public final int update(String id, String paraName, String paraValue) ；
/*
	 * 根据ID查询方法 返回Bean对象
	 */
	public final Bean findById(Object id) ；
/*
	 * 提供一个可以自定义SQL明了的query方法
	 * 此SQL语句允许跨操作权限查询其它表，所以整个SQL语句由具体的Dao来组成
	 * 参数1：String preparedSsql--->preparedSql语句
	 * 参数1：Object[] values--->preparedSql语句中的参数队列
	 * 没有调用closePreparedStatement 应该显式的调用this.freeConnection()释放连接
	 */
	protected  ResultSet query(String preparedSsql,Object[] values) ；
/*
	 * 提供一个可以自定义SQL明了的Execute方法
	 * SQL命令封装了“update ”+表名称,所以使用时只需传入“set”及以后的字符串
	 * 参数1：String preparedSsql--->preparedSql语句
	 * 参数1：Object[] values--->preparedSql语句中的参数队列
	 * 返回1为操作成功 0为没有执行操作 -1为出异常了
	 */
	protected int execute(String preparedSsql,Object[] values) ；
/*
	 * 查找方法，根据ID和列名来查找属性的值
	 * 参数1：String id--->记录id
	 * 参数2：String paraName--->列名称
	 */
	public Object getParaValueById(String id,String paraName)；
/*
	 * 删除方法，传入对象ID,int或者String皆可
	 * 返回1为操作成功 0为没有执行操作 -1为出异常了
	 */
	public final int delete(Object id) ；

4 楼 zozoh 2009-05-26  

我觉得你的思路挺清楚的，这样的结构也挺清晰的。
New 一个对象的消耗，在 Java 中可以忽略不计，你大可放心。

这个框架应该很贴合你们的业务，我觉得如果弄出来，肯定很不错。关键是，你打算怎么实现你的 AbstractDao 呢？ 能贴一下 AbstractDao 的接口函数定义吗？

3 楼 01404421 2009-05-25  

mccxj 写道

扫描扫描：
AbstractNoUserAction? 不需要登录的Action？使用个Protectable的接口更好，没有实现这个接口的就是nouser的，可以自己发挥。。
权限怎么只有角色？用户呢？最基本也得有个rbac简单模型把。DemoAction怎么直接调用Role了，应该使用业务逻辑隔开
不大明白AbstractDao和权限检查，日志，异常统一处理有什么关系
Bean那块要实现hiberante那样类似的功能，可不容易

Action的涉及范围太广，分层变得没意义了。
业务层更不能不要。。dao层在强大的orm/sqlmapping下反倒可以省略
hibernate太麻烦，可以考虑ibatis，一天之内应该可以上手
图用visio画的么？你这个已经整了好几大块了。可以考虑用个整体的简图配上各个部分的详细点的设计，手工画画也不错

谢谢指导，
我的权限其实是这样控制的，角色中封装了操作权限，因为所有Bean都是可以调用Abstract Dao的子类来操作的，为了防止跨权限操作表，所以在Abstract Dao中对权限进行检查，这样导致一层层的直到Action也必须往下传角色.....
还在困扰中，Abstract NoUserAction中Role是计划要传入IP，还要记录操作日志记录
角色中带有ID的，可以区分用户，这样同时也可以对角色的操作进行处理（比如积分和操作日志等，同时数据库操作异常也可以在这里处理）
至于Action的涉及范围，我对这个还没有多少概念，还需要学习
业务层方面，我们的操作逻辑比较简单，同志们都建议不需要了（我们大家都没有开发经验），就是类调类传个参数
至于画图还是刚学的，呵呵，是用Visio做的，以前也没有画图的习惯，要慢慢学习！

2 楼 mccxj 2009-05-25  

扫描扫描：
AbstractNoUserAction? 不需要登录的Action？使用个Protectable的接口更好，没有实现这个接口的就是nouser的，可以自己发挥。。
权限怎么只有角色？用户呢？最基本也得有个rbac简单模型把。DemoAction怎么直接调用Role了，应该使用业务逻辑隔开
不大明白AbstractDao和权限检查，日志，异常统一处理有什么关系
Bean那块要实现hiberante那样类似的功能，可不容易

Action的涉及范围太广，分层变得没意义了。
业务层更不能不要。。dao层在强大的orm/sqlmapping下反倒可以省略
hibernate太麻烦，可以考虑ibatis，一天之内应该可以上手
图用visio画的么？你这个已经整了好几大块了。可以考虑用个整体的简图配上各个部分的详细点的设计，手工画画也不错

1 楼 ztbzg 2009-05-25  

能自己写框架，相当佩服。希望有高手出来指正，我也在学习中。