你好：

1. mybatis和jdbctemplate比較，的確jdbctemplate可以讓你非常自由的寫代碼，就像直接寫sql語句一樣，但是這些自由度在企業級的團隊內的應用是災難性的，首先，所有人的代碼落地都是基于自己的業務場景，放縱的寫sql，用join，當然，必要的多對多的join是可以的，但是好幾張甚至好幾十張表關聯在一起的應用是沒有辦法維護的，到那一天所有人都會發現我們的應用是完全面向數據庫的設計風格，而不是面向業務模型的，等到業務發生了變化所有人都要看代碼改代碼到底層的sql語句級別，而且多join的數據表操作在上萬數據后都是沒有任何性能優化的空間，索引都不知道往哪里加，因此mybatis提供的是orm的一套框架，不是說mybatis好，而是orm在業務模型的應用中好，將數據庫當作簡單的存儲，業務應用只感知領域模型，模型及是業務，性能優化也圍繞模型去做，用緩存存模型而非單純靠sql語句優化。

2. 用戶和密碼對應的一對一關系的確可以用mybatis的關系映射做，但是試想日后我們數據庫龐大到一定程度了需要拆庫分表，我們第一個想到的是將只有登陸會用的密碼表放到另一個數據庫，將現在的user數據表放在獨立的數據庫內提升用戶查詢方面的效率，這個時候一個mybatis的映射是無法跨兩個數據源的，因此性能優化又會碰到問題。我強烈推薦數據庫和mybatis的dataobject做一對一關系，既方便代碼的維護，又可以清晰的在model層面理清領域模型的處理關系。當然針對一些聯合查詢排序的問題還是要依靠join的。我說的絕對不是不用join，而是可以依靠單表操作解決的一定不要用join