問：
我們公司用準備採用Com+技術開發應用程序，可在怎麼實現上有了
分歧，主要矛盾在查詢部分，分爲兩派：
1。一派認爲查詢只是簡單的數據選擇，提議把基本SQL語句存到數據庫裏的
一個表中，由客戶端拼湊查詢條件，在業務邏輯層再從數據庫裏把基本SQL語句讀出來接到一起去檢索數據，整個系統的查詢都調用同一個查詢接口。
2。另一派認爲查詢也是屬於業務邏輯範疇，並不是簡單的SQL語句拼湊，
應該分成不同的接口來實現，客戶端只向業務邏輯層傳一些參數，由業務邏輯層傳回處理結果。
我們曾展開過激烈的討論，覺得問題應該主要集中在下面幾個部分：
1。查詢只是簡單的數據檢索還是業務邏輯？如果是業務邏輯，那麼第一種方式的業務邏輯實現是在數據庫端還是應用服務器端。
2。如果採用第一種方式開發，那麼對團隊合作開發效果是否好？比如說各子系統之間的相互調用就必須公開自己的SQL語句，而不是提供獨立的接口。
3。一個系統中視圖的使用應該有怎樣的原則？如果視圖數量超過數據表的數量的話，對開發和系統升級有什麼影響？
因爲我們水平有限，誰也說服不了誰，只能請求援助了，不知各位大俠有何高見？
1、不管是否對SQL語句進行硬編碼或序列化，它都是邏輯層數據訪問接口和數據層之間的協議。
2、在關係數據庫的三個模式中，SQL操縱語句的設計就是應用模式的設計。
3、使用三層客戶服務器結構使你的應用程序更容易擴展和佈署。
4、對SQL語句實現序列化是參數化設計的一個辦法，但需要對數據訪問接口充分的抽象和設計。
5、序列化後SQL代碼存放在業務數據庫裏會增加邏輯層與數據層的耦合程度，不利於數據層的靈活佈署。
6、SQL的序列化數據建議使用獨自的參數化文件或本地數據庫實現。
7、對於數據訪問複雜性不高的應用，僅僅使用動態SQL代碼，設計一個數據訪問子層集中SQL語句就可以達成目的。
作者：linchangping 轉貼自：www.umlchina.com