分享公司DAO層動態SQL的一些封裝

 

主題

　　公司在DAO層使用的框架是Spring Data JPA,這個框架很好用,基本不需要自己寫SQL或者HQL就能完成大部分事情,但是偶爾有一些復雜的查詢還是需要自己手寫原生的Native SQL或者HQL.同時公司前端界面使用的是jquery miniui框架,並且自己進行了一些封裝.

　　當界面上查詢條件比較多的時候,需要動態拼接查詢條件,使用JPA的話可以通過CriteriaQuery進行面向對象的方式進行查詢,但是偶爾有時候又要用到HQL或者SQL,畢竟比CriteriaQuery簡單很多.而兩者似乎不能很好的結合(我還沒見過將兩者混用的,不過可能是我CriteriaQuery使用的比較少的原因).

　　這也是我寫這篇文章的原因,記錄分享一下公司的解決辦法(公司的策略也不是完美的,只能適用於簡單的查詢,復雜的情況還是不支持的,但是也不失為一種解決辦法)

 

原理

　　公司動態查詢的原理是使用HQL或者SQL,在這個基本select語句上動態拼接where條件...公司認為用戶在界面上動態選擇條件的時候,select 的表基本是不會變化的,有變化的是where字句里的條件.所以需要對用戶的輸入和where子句里的條件進行封裝.

　　DefaultPage:這個類是公司對前端界面用戶輸入的查詢條件,比如分頁信息等等進行的封裝.(當然還有其他很多類..只是這個是最主要的,怎么封裝的不是這篇文章的主題)

　　SearchCriteria:這個是公司對查詢條件where子句的封裝,它可以通過一些方法轉化成where子句里SQL字符串..

　　最主要的就是以上2個類,核心思想就是封裝用戶輸入的查詢信息到DefaultPage,從DefaultPage中取得SearchCriteria,將SearchCriteria轉化成字符串形式,拼接在基礎的SQL(HQL)之上,形成動態的SQL來查詢數據.

 

主要實現

SearchCriteria

SearchCriteria是對where子句的封裝,SearchCriteria中包含很多個小的SubCriteria,SubCriteria是對where子句里每個條件的封裝.

比如有個where子句是:

where 1=1 and user.username = 'user1' and user.state in ('0','1');

那整個where語句是1個SearchCriteria  

and user.username = 'user1'是第一個SubCriteria 

and user.state in ('0','1')是第二個SubCriteria

1=1是為了拼接方便,就算沒有查詢條件也拼接where條件而增加的一個拼接默認條件

    public SubCriteria(String attName, EOperator operator, Object value, ERelation relation, String tabelAlias) {
        this.attName = attName;
        this.operator = operator;
        this.attValue = value;
        this.relation = relation;
        this.tableAliasName = tabelAlias;
    }

從SubCriteria的構造方法中可以看出,如果一個SubCriteria對應的是and user.username = 'user1'

那attName就是username

operator就是=

value就是'user1'

relation就是and

tableAlias就是user

 

1個SearchCriteria中肯定會含有N個SubCriteria

List<SubCriteria> list = new ArrayList<SubCriteria>();

 

查詢的數據庫結果的方法如下:

    @Override
    public <D> List<D> executeDynamicQuerySql(String sql, SearchCriteria criteria, Class<? extends D> targetClass,
            Map<String, Object> customParams) {
        Map<String, Object> paramMap = new HashMap<String, Object>();
        String handledSql = calculateDynamicSql(sql, criteria, paramMap);
        mergeCustomParams(paramMap, customParams);
        return NativeSqlExecutor.executeQuerySql(getEntityManager(), handledSql, paramMap, targetClass);
    }

sql的格式就是類似於 select * from user user %Where_Clause% and user.yxbz = :yxbz     (yxbz是有效標志的意思)

criteria就是界面上動態選擇的查詢條件和值的封裝

targetClass不重要,只是為了把結果封裝成對象時候,指定要封裝到哪個類型的對象里.(數據庫返回結果封裝到對象也是公司自己封裝的代碼)

customParams 里存是sql里一些占位符參數的鍵值對,比如key=yxbz,value='Y'

 

第5行代碼calculateDynamicSql將Criteria轉化成的SQL拼接到傳入的sql中,替換掉%Where_Clause%,在把Criteria中的占位符鍵值對放到paramMap中

第6行,將paramMap與傳入的customParams合並,得到一個合並的map,即是把customParams的鍵值對放到paramMap中.

第7行就是常規的調用JPA的方法,把生成的動態的SQL與參數Map傳給JPA去執行,根據targetClass將返回的結果封裝成對象.

 

calcilateDynamicSql具體步驟如下:

    private String calculateDynamicSql(String sql, SearchCriteria criteria, Map<String, Object> paramMap) {
        String searchSql = calculateSearchDynamicSql(sql, criteria, paramMap);
        return calculateOrderDynamicSql(searchSql, criteria);
    }

private String calculateSearchDynamicSql(String sql, SearchCriteria criteria, Map<String, Object> paramMap) {
        StringBuilder whereClause = new StringBuilder(" WHERE 1=1 ");
        int index = paramMap.keySet().size() + 1;
        for (SubCriteria subCriteria : criteria.getCreteriaList()) {
            whereClause.append(subCriteria.getRelation().getCode());
            whereClause.append(StringUtils.isEmpty(subCriteria.getTableAliasName()) ? "" : subCriteria
                    .getTableAliasName() + ".");
            whereClause.append(subCriteria.getAttName());
            whereClause.append(" ");
            whereClause.append(subCriteria.getOperator().getCode());
            whereClause.append(" ");
            if (EOperator.IN == subCriteria.getOperator()) {

                @SuppressWarnings("unchecked")
                List<Object> paramValues = (List<Object>) subCriteria.getAttValue();
                whereClause.append("(");
                for (int i = 0; i < paramValues.size(); i++) {
                    whereClause.append(PLACEHOLDER);
                    String key = PARAM_PREFIX + (index++);
                    whereClause.append(key);
                    if (i != paramValues.size() - 1) {
                        whereClause.append(",");
                    }
                    paramMap.put(key, paramValues.get(i));
                }
                whereClause.append(")");
            } else {
                whereClause.append(PLACEHOLDER);
                String key = PARAM_PREFIX + (index++);
                whereClause.append(key);
                whereClause.append(" ");
                paramMap.put(key, subCriteria.getAttValue());
            }
        }
        return sql.replace("%WHERE_CLAUSE%", whereClause.toString());
    }

calculateDynamicSql中又分為2個步驟,先根據SearchCriteria計算出where字符串,再根據SearchCriteria計算order by子句...order by子句比where子句簡單很多,原理也差不多...就不介紹了..主要看calculateSearchDynamicSql這個計算where子句的方法步驟主要是:

1.先拼接where 1=1 這是為了簡化問題,防止用戶什么都不選的時候不用拼接where子句的問題,就算動態SQL里什么where條件都不寫,也會拼接where 1=1 這個條件來簡化問題.

2.有了步驟1可以保證一定拼接了where字符串,后續只要把SubCriteria轉化成字符串拼接到where子句中就OK了. 拼接方法如前面介紹SubCriteria所說,就是把SubCriteria中的屬性一個一個取出來拼接.唯一有點區別的就是如果SubCriteria中EOperator是in操作符,那傳過來的參數值是個list而不是一個String...

 

mergeCustomParams(paramMap, customParams)方法

拼接完了SQL,就需要把SearchCriteria中的占位符鍵值對與用戶傳入的鍵值對合並.

    private void mergeCustomParams(Map<String, Object> paramMap, Map<String, Object> customParams) {
        if (null == customParams || null == paramMap) {
            return;
        }
        for (Map.Entry<String, Object> entry : customParams.entrySet()) {
            if (null != entry.getKey()) {
                if (paramMap.containsKey(entry.getKey())) {
                    throw new IllegalArgumentException("動態SQL不允許自定義占位符以 'P_' 開始，該類占位符用於 searchCriteria動態生成。");
                }
                paramMap.put(entry.getKey(), entry.getValue());
            }
        }
    }

當然其中鍵值對可能會有同名的...那就報錯...

 

executeQuerySql方法

    public static <D> List<D> executeQuerySql(EntityManager entityManager, String sql, Map<String, Object> paramMap,
            Class<? extends D> targetClass) {

        LOGGER.debug("Execute native query sql {} with parameters {} for target {}", sql, paramMap, targetClass);
        Query query = entityManager.createNativeQuery(sql);
        if (DbColumnMapper.isNamedMapping(targetClass)) {
            query.unwrap(SQLQuery.class).setResultTransformer(Transformers.ALIAS_TO_ENTITY_MAP);
        }
        if (paramMap != null) {
            for (Entry<String, Object> entry : paramMap.entrySet()) {
                query.setParameter(entry.getKey(), entry.getValue());
            }
        }
        return DbColumnMapper.resultMapping(query.getResultList(), targetClass);
    }

核心就是:

1.query.setParameter(entry.getKey(), entry.getValue());根據傳入的鍵值對設置到占位符中

2.query.getResultList()查詢結果..其他很多代碼是用於把query.getResultList()的結果封裝成對象用的..主要方法是在targetClass的類的Field上使用注解標注.

 

DefaultPage

公司對前后台請求與參數都進行了封裝,前面寫過一篇文章,介紹了公司的基本思路(當然實現肯定不一樣)

http://www.cnblogs.com/abcwt112/p/5169250.html

所以這里不再詳細介紹前台用戶選擇的那些查詢條件怎么封裝到DefaultPage里了...

 

我們來看看DefaultPage如何生成SearchCriteria的:

private SearchCriteria buildSearchCriteria(String buildSearchType) {
        SearchCriteria search = new SearchCriteria();
        operationMap = this.getOperationMap();
        try {
            for (Map.Entry<String, Object> entry : parameterMap.entrySet()) {
                String paramKey = entry.getKey();
                Object value = parameterMap.get(paramKey);
                boolean isString = value instanceof String;

                if (value != null) {
                    if (isString) {
                        if (StringUtils.isNotEmpty((String) value)) {
                            search.add(this.getColumnName(paramKey, buildSearchType), this.parameterMap.get(paramKey),
                                    operationMap.get(paramKey));
                            this.parameterValues.add(value);
                        }
                    } else {
                        search.add(this.getColumnName(paramKey, buildSearchType), this.parameterMap.get(paramKey),
                                operationMap.get(paramKey));
                        this.parameterValues.add(value);
                    }

                }
            }
            for (SearchOrder order : orderBy) {
                if (StringUtils.isNotEmpty(order.getOrderName())) {
                    SearchOrder realOrder = new SearchOrder(this.getColumnName(order.getOrderName(), buildSearchType),
                            order.isAsc());
                    search.getOrderByList().add(realOrder);
                }
            }

        } catch (Exception ex) {
            throw new SystemException(SystemException.REQUEST_EXCEPTION, ex, ex.getMessage());
        }
        return search;
    }

buildSearchType有2種,1種最常用的就是生成我們這里一般的SQL查詢的searchCriteria,還有一種適用於SpringDataJpa,用於生成適用於Specification接口的SearchCriteria用的...

 

生成SearchCriteria主要是為了生成SubCriteria,通過調用SearchCriteria的add方法直接在生成一個SubCriteria並放到SearchCriteria的List<SubCriteria>成員域中.

                            search.add(this.getColumnName(paramKey, buildSearchType), this.parameterMap.get(paramKey),
                                    operationMap.get(paramKey));

    public void add(String attribute, Object value, EOperator operator) {
        if (attribute == null || operator == null) {
            return;
        }
        list.add(new SubCriteria(attribute, operator, value));
    }

search.add的第一個參數是attribute就是where user.username = :username中的username

 

getColumn方法如下:

    private String getColumnName(String paramKey, String buildType) throws Exception {// NOSONAR
        if (paramKey.indexOf(':') > 0) {
            String[] keys = paramKey.split(":");
            if (null != keys && keys.length == 2 && cmpClass != null) {
                Field field = cmpClass.getDeclaredField(keys[0]);
                if (null != field) {
                    StringBuilder sb = new StringBuilder();
                    sb.append(keys[0]);
                    sb.append('.');
                    if (BUILDTYPE_NATIVE.equalsIgnoreCase(buildType)) {
                        sb.append(getColumnName(keys[1], buildType, field.getClass()));
                    } else {
                        sb.append(keys[1]);
                    }
                    return sb.toString();
                }
            }
        }
        return getColumnName(paramKey, buildType, cmpClass);
    }

大多數情況下是直接調用19行的getColumnName

    private String getColumnName(String paramKey, String buildType, Class<?> clazz) throws Exception {// NOSONAR
        String columnName = paramKey;
        if (paramKey.endsWith("_start")) {
            columnName = paramKey.replaceAll("_start", "");
        }
        if (paramKey.endsWith("_end")) {
            columnName = paramKey.replaceAll("_end", "");
        }
        if (clazz != null && BUILDTYPE_NATIVE.equalsIgnoreCase(buildType)) {
            Field field = clazz.getDeclaredField(columnName);
            Column column = field.getAnnotation(Column.class);
            if (column != null) {
                columnName = column.name();
            }
        }
        return columnName;
    }

clazz是前台數據傳過來肯定會封裝到一個接受對象上,如果那個對象的field上用了注解@Column,那就取注解里寫的name作為attribute的name,否則就取前台傳過來的參數值作為attribute.

這是因為jpa的注解@column可以讓實體類里的字段映射到數據庫中表的字段,但是兩者的名字可以不同,將SearchCriteria轉化成SQL的時候用要使用數據庫中的字段名而不是實體類中的屬性名.

這樣就能構造出一個SearchCriteria了.

 

 

以上便是公司對DAO層動態SQL的主要封裝邏輯..在查詢條件不復雜的情況下還算好用...

但是查詢條件比較復雜的話就有點力不從心了..因為SearchCriteria里只有一個SubCriteria的list,而SubCriteria中不能包含SubCriteria...所以像 where (a.b = '1' or a.c = '2') and ....

這樣的查詢就做不出來...