在上个公司的项目中,由于用到了导师在年前所参与写的一个开源框架.http://www.open-open.com/open155318.htm 并在运用的过程中碰到些存在的问题,故将碰到的问题列出来,与大家分享.
由于是导师的框架,所以不存在什么乱改写的问题,况也只有内部在使用,其实也是为了自己开发上的需要,对原有的相关的代码进行功能上的补充和改进,以实现更多的功能.
1,对非持久性数据字段的支持,在原来的框架中,由于域模型字段与数据库字段一致,故采用自动保存,即调用save(object)时,它会自动分析对象的各个属性,并将所有的属性作为数据库的字段处理.而在实际中,并非所有的属性都需要被存储,如一些模型中的集合属性或者一些不用于数据存储的属性.参考原代码中用于代码存储的一段,即用于读取各个属性并生成sql语句这一行,加入特殊标记判断,对于transient的属性将其忽略,不将其列入存入数据库中的字段.(这个设计同样影响对于update等操作,不过由于数据库的相应表并不存在与transient属性对应的列,故此举并不会影响update操作的正常进行)相关代码如下:
- public static String getInsertSQL(Connection con, String dbtype,
- Object cls_pojo) throws SpeedException {
- StringBuffer ins_sql = new StringBuffer();
- StringBuffer value_sql = new StringBuffer();
- String table_name = getExcuteTableName(cls_pojo.getClass());
- try {
- Field[] fields = cls_pojo.getClass().getDeclaredFields();
- List keyList = new ArrayList();
- if (dbtype.indexOf("db2") != -1) {
- ins_sql.append("insert into ").append(TableUtils.getTableSchem(con, dbtype,
- table_name)).append(".").append(table_name).append("(");
- } else {
- ins_sql.append("insert into ").append(table_name).append("(");
- }
- value_sql.append("(");
- for(Field field : fields) {
- //Fly_m add here for associated properties such as list or array properties,if transient,ignore it.
- if(Modifier.isTransient(field.getModifiers()))
- continue;
- String column_ = getField(field);
- if(!column_.toLowerCase().equals("serialversionuid")) {
- Object value = PropertyUtil.getProperty(cls_pojo, column_);
- if(value != null && !value.toString().equals("")) {
- keyList.add(column_);
- }
- }
- }
- for (int i = 0; i < keyList.size(); i++) {
- if (i < keyList.size() - 1) {
- ins_sql.append(keyList.get(i)).append(",");
- value_sql.append("?,");
- } else {
- ins_sql.append(keyList.get(i)).append(")");
- value_sql.append("?)");
- }
- }
- ins_sql.append(" values ").append(value_sql.toString());
- } catch (Exception e) {
- throw new SpeedException(e.getMessage());
- }
- return ins_sql.toString();
- }
2,在上次的项目中,用这个框架对统计进行一次初始统计,居然不能正常完成.查其原因,发现在底层居然是采用每一次重新建立数据库连接并结束再建立的方式,且在建立过程中还要重新读一次配置文件.效率十分低下.解决方法,在配置过程中建立一个小小的配置缓存,在下一次读取时,直接返回相应缓存的结果.而重点在于如何解决每一次访问数据库都要重新建立连接的问题.由于此框架并没有实现连接池,查看了相应的代码,框架重新建立数据库连接无非也就是获得一个Connection对象,所以我想在其他地方引入一个connection对象(如池化的connection对象),并将其配入框架中,在框架的初始配置代码中引入connection属性,在获取连接时,首先尝试获得初始被外界传入的connection对象,如果外界没有传入,再由框架自身解析获得.仔细分析了一下代码,代码的入口点在EngineImpl类中,此类需要一个connection对象作为构造参数.所以,需要一个dataSource对象,再将dataSource对象产生的connection对象传入EngineImpl类的构造参数就OK了.这个connection对象是由外部的数据访问模板SpeedTemplate调入的,由SpeedTemplate只要接受一个可选的dataSource属性就可以实现将池化的connection对象传入整个框架中了,并且这个connection对象还由连接池来管理,而在框架中只是完成相应的数据访问操作.相应方式对比如下:
原先的方式:
java 代码
- EngineFactory.getEngine(connectionFactpublic static Engine getEngine(String connectionFactoryId) throws DataAccessResourceFailureException {
- try {
- return doGetEngine(connectionFactoryId);
- } catch(SpeedException ex) {
- throw new DataAccessResourceFailureException("Could not get Speed Engine", ex);
- }
- }
之后就是调用配置文件进行DriverManager.getConnection()并将connection传入EngineImpl如下
- public static Engine getEngine(String connection_factory_id)
- throws SpeedException {
- if(connection_factory_id == null || connection_factory_id.equals("")) {
- throw new SpeedException("The id does't not specify");
- }
- Connection con = ConnectionFactory.getConnection(false,
- connection_factory_id);
- return new EngineImpl(con);
- }
而修改之后的调用方式则如下:
- protected static Engine doGetEngine(DataSource dataSource) throws SpeedException {
- Assert.notNull(dataSource, "the dataSource must be not null");
- try {
- Connection conn = dataSource.getConnection();
- return new EngineImpl(conn);
- } catch(Exception e) {
- throw new SpeedException("Try get engine failure." + e);
- }
- }
这两者都是得到一个connection再将其传入EngineImpl,只是得到的方式不一样而已.在speedTemplate里面,得到一个Engine对象,首先判断dataSource属性是否为空,如果不为空,则采用dataSource的方式,否则采用getEngine(connectionFactoryId)即自已的解析方式.我还是喜欢连接池的方式.
3,模型字段与数据库字段大小写不一致的情况.我在用这个框架时,经常是手动书写插入和更新语句,因为我的对象的属性名都是大小写混合的,如testProperty,由数据库中的列为test_property,为了能让在查询中能够返回testProperty的列名,我经常采用select test_property as testProperty的写法.但还是报出property not found by :testproperty的异常,仔细看了下代码,发现代码中各处都是调用sql.toLowerCase()方法将sql语句转为小写.修改代码,将toLowerCase()去掉之后,问题解决.但是后来,将数据库转为oracle时,发现所有的列名又不可用了.仔细看了下oracle传回的数据,发现所有返回的列都是大写的!!!在mysql下,返回的列是跟程序中指定的列的大小写一致的,而到了oracle所有列都变成了大写了.在不改动项目程序的基础之上,尝试改写框架中对于返回数据处理这一段.在这一层建一个列属性(并将列属性改为小写)与对象属性名称之间的一个映射.列属性由传回的列名得到,而对象属性由对象本身通过反射得到.并将这一映射存入一个映射缓存中.在处理返回数据时,首先由得到列名及指定列的数据(由rs.getColumnName(int)得到),得到列名及数据之后,将列名.toLowerCase()之后与属性映射中得到正确的对象属性名称,再通过propertyUtils将指定的对象属性值写入正确的属性中去.相应代码如下:
- public static List copyRows(ResultSet rs, Class voclass) throws Exception {
- Object vo = null;
- ResultSetMetaData rsm;
- List relist;
- rsm = rs.getMetaData();
- relist = new ArrayList();
- Map entity = null;
- Map propertyMap = null;
- if(voclass != null) {
- propertyMap = BeanFieldCache.getPropertyMap(voclass);
- if(propertyMap == null)
- propertyMap = BeanFieldCache.register(voclass);
- }
- while(rs.next()) {
- if(voclass != null) {
- vo = voclass.newInstance();
- } else {
- entity = new HashMap();
- }
- for(int i = 1; i <= rsm.getColumnCount(); i++) {
- //2007-10-17 Fly_m update here must not toLowerCase for some Property should be uppderCase
- String columnRealName = rsm.getColumnName(i);
- String columnName = columnRealName.toLowerCase();
- Object value;
- if(voclass != null) {
- if(!columnName.equalsIgnoreCase("rownum") && !columnName.equalsIgnoreCase("rownum_") && !columnName.equalsIgnoreCase("count_")) {
- value = ConvertUtil.outPortData(rs, columnRealName,
- voclass);
- PropertyUtil.setProperty(vo, propertyMap.get(columnName), value);
- }
- } else {
- value = rs.getObject(i);
- entity.put(columnName, value);
- }
- }
- if(voclass != null) {
- relist.add(vo);
- } else {
- relist.add(entity);
- }
- }
- return relist;
- }
这样就实现了不同格式列名与属性之间的映射关系了.
这个框架是自从跟导师在一起学习的时候就在运用这个框架,当然它的若能远远不及hibernate等orm框架.不过在进行简单的开发上面,还是不错了.现在仍然在用,是因为实习的公司要求用这个,(因为导师跟公司的关系很好,框架都是导师介绍过去的).在运用的过程中,发现新的问题,也想要去解决它.可能是这个框架不太成熟吧,导致它有太多的bug了,不过对于现在的学习还是不错的.尤其是对于它的属性映射,及sql语句的动态生成,了解一下,对hibernate之类的框架的工作原理还是有一定帮助的. 在跨平台上,也可能有一些值得借鉴的地方. 我最欣赏的还是框架对于分页的处理.在hibernate中,需要配置不同的dialect属性,才能运用数据库自身的分页功能,而speed则尝试自己获得数据库的属性,然后根据不同的数据库属性采用特定于数据库的分页方式.其底层原理和hibernate都是差不多的.任何框架,只会用,而不知其所以然,到头来也是什么也不知道,了解多一些,自己掌握多一些总是好的.