你好：

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

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