昨天給大家分享了mapper代理方法開發dao，今天來給大家分享一下原始dao開發方法有哪些弊端。
原始dao開發思路比較簡單，寫個dao接口和dao實現類即可。需要向dao實現類中注入sqlSessionFactory，在方法體內通過sqlSessionFactory創建sqlSession。爲什麼在方法體內創建呢？因爲mybatis中sqlSession是線程不安全的。如果在方法外面以成員變量的方式創建，可能會引發線程安全問題。下面總結一下原始dao開發的步驟：
1. 寫UserDao接口
2. 寫UserDaoImpl實現類
從UserDaoImpl實現類中可以看出，首先SqlSessionFactory需要注入進來，這裏通過構造函數來注入，傳個SqlSessionFactory進來即可完成注入。另外，sqlSession都是在具體方法內部創建的，沒有將sqlSession放到外面，因爲在方法內部，相對於每個線程是獨立的，不會引起線程安全問題。至於每個方法內部的實現，和上一節的入門程序邏輯一樣。
3. 寫單元測試UserDaoImplTest
從JUnit測試程序中可以看出，通過@Before註解，將SqlSessionFactory在測試方法執行之前初始化好，然後在測試方法中，直接通過構造函數傳進去即可，這就和上面的UserDaoImpl實現類接上了。然後測試一下添加用戶即可。
4. 原始dao開發存在的問題
從上面的代碼中，可以很明顯的看出原始dao開發方式有以下弊端：
1. dao接口實現類方法中存在大量重複代碼，從設計上來看，應該抽取。
2. 調用sqlSession方法時，將satement的id硬編碼了，即類似於”test.findUserById”這種，都寫死了。
3. sqlSession的方法中，要求傳入的參數是Object類型的(泛型)，也就是說如果我傳錯了參數，編譯不會報錯，執行的時候纔會報錯，不利於開發。
這些都是原始dao開發方式中存在的問題，在瞭解了原始dao開發方式的問題後，再來使用mapper代理開發dao，就可以形成鮮明的對比了。