面向解決問題的java編程，spring boot，mybatis generator和坑-0廢話篇

    當一個立志成爲程序員的人開始一門新技術的學習時，是很興奮的，由於不少新技術的介紹老是有不少酷炫的新名稱，酷炫的新功能和一些與舊技術的對比，在對比中，新技術老是用各類對比數據把舊數據踩在腳底，彰顯本身的高富帥。因而，火燒眉毛的新手開始了新技術的探索之旅，全然忘記了他爲何要學習這門新技術，雙眼也看不清這些酷炫技術後面的坑。因而，當新技術的酷炫外衣剝去以後，坑歷歷在目，連上網絡，搜索半天卻由於技術太新而無人應答，這時候新手變成了怨念在苦手，在坑中暗暗哭泣。

    我對新的技術老是很提防，由於它就像遊戲的戰爭迷霧，風險隱藏其中，不走近根本就不知道。但一門技術的出現，老是光芒萬丈，都是要砸掉舊技術的鎖鏈，解放生產力，提升一個數量級的性能，等等等等，好不誘惑。怎麼平衡技術的風險和效益呢，下面我說下個人判斷標準。

    對我而言，我通常從很世俗的標準來評判這個問題，那就是是否能幫我解決問題。是的，我通常都是心懷問題在各類技術中游走，只有這樣，你纔會知道你要什麼，對我而言，我須要的第同樣東西，就是少幹活，多產糧。爲何要用spring，由於IOC？由於POJO？由於AOP?No，都9012年，誰還在意這個，我用spring的惟一緣由是它幾乎關聯了市面上全部的流行工具，各類DAO（hibernate，mybatis），各類MQ（activemq，rabbitmq），各類緩存（memcache，redis），基本上你們用的主流技術工具或多或少都能和spring關聯上，這樣就極大的節省我用各類工具的時間。到spring boot的時候，其實我是有意見的。由於spring boot號稱是爲了簡化你們的配置工做，但在現實的業務的世界，複雜是不可避免的，若是在入門的時候簡單了，那麼在後面必將要補回來的，由於複雜的本質是業務的複雜，沒有誰可以抹平復雜的業務，因此複雜的配置也必然存在。可是start的出現解決了spring和各類工具的依賴包問題，這個確確實實的比我自個在maven的pom中去加jar包要省事的多，jar地獄的問題有所緩解。因此我最後決定使用spring boot的最大緣由，就是starter。記住這個緣由很重要，由於咱們每用一個新的技術工具，技術框架，其實都要明確的問本身，爲何要用，解決了什麼問題。

    而後再說下mybatis，mybatis通常的說法是比hibernate要靈活，要輕量級。但很差意思，我一開始就不是用mybatis對標hibernate，由於個人sql還不錯，因此對任何包裝sql的dao工具都不是感冒，我都能用sql搞定了，爲啥要用一個包裹了sql的工具。是的，我對標的是jdbctemplate，它其實很好用，靈活好用，簡單方便，我如今有時候仍是喜歡它。那爲何要用mybatis呢，由於它能返回dataobject？這是一個緣由，由於一個數據對象的可讀性，比用jdbctemplate返回的map要好看一些，但這不是根本緣由，由於jdbctemplate也能夠返回 數據對象，mybatis並無絕對的優點。是的，我最終選擇的其實不是mybatis，而是mybatis generator，由於它能夠幫我生成全部基礎的crud代碼，我不須要改任何東西。擁有它，我就擁有了全部數據表的dataobject和全部的CRUD，是針對全部表的全部字段的查詢，這個很重要，由於我已經不肯意一遍又一遍的寫基本的CRUD語句了，特別是修改了數據庫表的時候。這就是選擇mybatis generator的緣由，我不想寫CRUD，不想改CRUD操做代碼，這就是我須要用它解決的問題。

    這一篇算是廢話，由於程序員通常不愛看這個，show me the code，下一章，咱們開始從spring  boot的新建項目開始，但我不會簡單的重複別人的作法，我會在創建的時候，帶上我掉的坑來說。