這裡我們不介紹如何進行解析生成sql語句，怎麼解析的不重要，只要知道這些都是解析類，轉換為sql語句的不同部分。我是想說說針對上面的需求，我是如何考慮的。
需要能夠使用sqlserver的函式？大概想一想，感覺很容易啊，不就是封裝乙個函式類，實現sqlserver資料庫的函式。是的，最根本的實現也就是這些。那還有什麼需要考慮的呢？那就來找找什麼是變化的。首先想到的肯定是不同的資料庫，能支援sqlserver資料庫，當然也得考慮擴充套件到oracle資料庫，
這樣就找到乙個變化點。（沒辦法，公司系統主要是mis，所以動不動就要關心不同的資料庫）支援不同資料庫，沒問題，每個函式都實現不就好了嗎，沒什麼大不了的。開啟資料庫函式列表，我暈，一大堆，如果都要實現，我看這個框架也就別做了，忙著實現這些函式功能就好了。而且，現在也不知道以後的新系統會用到哪些函式。最常用的函式肯定需要實現，用的多啊。如果哪天需要用到乙個新的資料庫函式而又資料層又沒有實現，怎麼辦？有辦法，修改函式類，增加乙個方法即可。嗯，不錯，解決了問題。問題是，乙個、兩個可以，日子長了，不得改個沒完。所以資料庫不斷增加的函式是第二個變化點。
暫時只找到了兩個變化點，現在該如何來封裝這兩個變化點？我是這樣來做的，針對不同資料庫，採用了strategy模式，這樣可以實現不同資料的函式解析。第二個變化點，為了能動態的支援資料庫的函式，選擇了visitor模式，這樣在實現了常用函式後不用擔心修改不斷增加的資料庫函式了。
好了，下週繼續。
對了，簡圖如下：
策略模式在工作中應用
物流系統要新增包裹資料，現在物流的上游有三種包裹 線上的包裹，線下的包裹，外部的包裹，每種包裹在新增時會有些不同的操作，比如線上線下的包裹新增後要發訊息給訂單履約中心方便監控，線上包裹新增時要判斷包裹是否需要抽檢，釘箱，並生成相關的資料等。每種包裹都有其特殊的操作，從系統維護的角度上說，可以使用策略...
策略模式在工作中的應用
最近在日常工作過程中接到乙個任務 需要提供乙個介面，根據不同的意圖返回給客服端不同的答案，每個意圖去識別答案的演算法都有各自不同的邏輯。作為乙個合格的crud程式設計師，接到這個需求腦袋裡的第一反應就是用if else去實現，但是這樣寫 太醜陋了，每個else裡面都會有大量的業務邏輯，對於後期接坑的...
責任鏈模式在工作中應用
判斷配件是否需要抽檢，現在系統有三種抽檢規則 商品規則，組織規則，其它規則，配件滿足任一規則即需要抽檢 因為配件要依次經過三種規則，所以考慮使用責任鏈模式 讓配件依次匹配商品規則，組織規則，其它規則，滿足任一規則即返回，不滿足繼續用下一規則判斷。結構 1.策略模版，建立乙個抽象類 commonins...