MongoDB的無縫集成，重拾後端之Spring Boot

MongoDB是什麼？ MongoDB是一個NoSQL數據庫，是NoSQL中的一個分支：文檔數據庫。和傳統的關係型數據庫好比Oracle、SQLServer和MySQL等有很大的不一樣。傳統的關係型數據庫（RDBMS）已經成爲數據庫的代名詞超過20多年了。對於大多數開發者來講，關係型數據庫是比較好理解的，表這種結構和SQL這種標準化查詢語言畢竟是很大一部分開發者已有的技能。那麼爲何又搞出來了這個什麼勞什子NoSQL，並且看上去NoSQL數據庫正在飛快的佔領市場。 NoSQL的應用場景是什麼？ 假設說咱們如今要構建一個論壇，用戶能夠發佈帖子（帖子內容包括文本、視頻、音頻和圖片等）。那麼咱們能夠畫出一個下圖的表關係結構。

論壇的簡略ER圖 這種狀況下咱們想一下這樣一個帖子的結構怎麼在頁面中顯示，若是咱們但願顯示帖子的文字，以及關聯的圖片、音頻、視頻、用戶評論、贊和用戶的信息的話，咱們須要關聯八個表取得本身想要的數據。若是咱們有這樣的帖子列表，並且是隨着用戶的滾動動態加載，同時須要監聽是否有新內容的產生。這樣一個任務咱們須要太多這種複雜的查詢了。 NoSQL解決這類問題的思路是，乾脆拋棄傳統的表結構，你不是帖子有一個結構關係嗎，那我就直接存儲和傳輸一個這樣的數據給你，像下面那樣。 { "id":"5894a12f-dae1-5ab0-5761-1371ba4f703e", "title":"2017年的Spring發展方向", "date":"2017-01-21", "body":"這篇文章主要探討如何利用Spring Boot集成NoSQL", "createdBy":User, "images":["dev.local/myfirstimag…"], "videos":[ {"url":"dev.local/myfirstvide…", "title":"The first video"}, {"url":"dev.local/mysecondvid…", "title":"The second video"} ], "audios":[ {"url":"dev.local/myfirstaudi…", "title":"The first audio"}, {"url":"dev.local/mysecondaud…", "title":"The second audio"} ] } NoSQL通常狀況下是沒有Schema這個概念的，這也給開發帶來較大的自由度。由於在關係型數據庫中，一旦Schema肯定，之後更改Schema，維護Schema是很麻煩的一件事。但反過來講Schema對於維護數據的完整性是很是必要的。 通常來講，若是你在作一個Web、物聯網等類型的項目，你應該考慮使用NoSQL。若是你要面對的是一個對數據的完整性、事務處理等有嚴格要求的環境（好比財務系統），你應該考慮關係型數據庫。 在Spring中集成MongoDB 在咱們剛剛的項目中集成MongoDB簡單到使人髮指，只有三個步驟： 在 build.gradle 中更改 compile('org.springframework.boot:spring-boot-starter-web') 爲 compile("org.springframework.boot:spring-boot-starter-data-rest") 在 Todo.java 中給 private String id; 以前加一個元數據修飾 @Id 以便讓Spring知道這個Id就是數據庫中的Id 新建一個以下的 TodoRepository.java package dev.local.todo; import org.springframework.data.mongodb.repository.MongoRepository; import org.springframework.data.rest.core.annotation.RepositoryRestResource; @RepositoryRestResource(collectionResourceRel = "todo", path = "todo") public interface TodoRepository extends MongoRepository<Todo, String>{ }

此時咱們甚至不須要Controller了，因此暫時註釋掉 TodoController.java 中的代碼。而後咱們 ./gradlew bootRun 啓動應用。訪問 http://localhost:8080/todo 咱們會獲得下面的的結果。 { _embedded: { todo: [ ] }, _links: { self: { href: "http://localhost:8080/todo" }, profile: { href: "http://localhost:8080/profile/todo" } }, page: { size: 20, totalElements: 0, totalPages: 0, number: 0 } }

我勒個去，不光是有數據集的返回結果 todo: [ ] ，還附贈了一個links對象和page對象。若是你瞭解 Hypermedia 的概念，就會發現這是個符合 Hypermedia REST API返回的數據。 說兩句關於 MongoRepository<Todo, String> 這個接口，前一個參數類型是領域對象類型，後一個指定該領域對象的Id類型。 Hypermedia REST 簡單說兩句Hypermedia是什麼。簡單來講它是可讓客戶端清晰的知道本身能夠作什麼，而無需依賴服務器端指示你作什麼。原理呢，也很簡單，經過返回的結果中包括不只是數據自己，也包括指向相關資源的連接。拿上面的例子來講（雖然這種默認狀態生成的東西不是頗有表明性）：links中有一個profiles，咱們看看這個profile的連接 http://localhost:8080/profile/todo 執行的結果是什麼： { "alps" : { "version" : "1.0", "descriptors" : [ { "id" : "todo-representation", "href" : "http://localhost:8080/profile/todo", "descriptors" : [ { "name" : "desc", "type" : "SEMANTIC" }, { "name" : "completed", "type" : "SEMANTIC" } ] }, { "id" : "create-todo", "name" : "todo", "type" : "UNSAFE", "rt" : "#todo-representation" }, { "id" : "get-todo", "name" : "todo", "type" : "SAFE", "rt" : "#todo-representation", "descriptors" : [ { "name" : "page", "doc" : { "value" : "The page to return.", "format" : "TEXT" }, "type" : "SEMANTIC" }, { "name" : "size", "doc" : { "value" : "The size of the page to return.", "format" : "TEXT" }, "type" : "SEMANTIC" }, { "name" : "sort", "doc" : { "value" : "The sorting criteria to use to calculate the content of the page.", "format" : "TEXT" }, "type" : "SEMANTIC" } ] }, { "id" : "patch-todo", "name" : "todo", "type" : "UNSAFE", "rt" : "#todo-representation" }, { "id" : "update-todo", "name" : "todo", "type" : "IDEMPOTENT", "rt" : "#todo-representation" }, { "id" : "delete-todo", "name" : "todo", "type" : "IDEMPOTENT", "rt" : "#todo-representation" }, { "id" : "get-todo", "name" : "todo", "type" : "SAFE", "rt" : "#todo-representation" } ] } }

這個對象雖然咱們暫時不是徹底的理解，但大體能夠猜出來，這個是todo這個REST API的元數據描述，告訴咱們這個API中定義了哪些操做和接受哪些參數等等。咱們能夠看到todo這個API有增刪改查等對應功能。 其實呢，Spring是使用了一個叫 ALPS （alps.io/spec/index.… 的專門描述應用語義的數據格式。摘出下面這一小段來分析一下，這個描述了一個get方法，類型是 SAFE 代表這個操做不會對系統狀態產生影響（由於只是查詢），並且這個操做返回的結果格式定義在 todo-representation 中了。 todo-representation { "id" : "get-todo", "name" : "todo", "type" : "SAFE", "rt" : "#todo-representation" }

仍是不太理解？不要緊，咱們再來作一個實驗，啓動 PostMan （不知道的同窗，能夠去Chrome應用商店中搜索下載）。咱們用Postman構建一個POST請求：

用Postman構建一個POST請求添加一個Todo 執行後的結果以下，咱們能夠看到返回的links中包括了剛剛新增的Todo的link http://localhost:8080/todo/588a01abc5d0e23873d4c1b8 （ 588a01abc5d0e23873d4c1b8 就是數據庫自動爲這個Todo生成的Id），這樣客戶端能夠方便的知道指向剛剛生成的Todo的API連接。

執行添加Todo後的返回Json數據 再舉一個現實一些的例子，咱們在開發一個「個人」頁面時，通常狀況下除了取得個人某些信息以外，由於在這個頁面還會有一些能夠連接到更具體信息的頁面連接。若是客戶端在取得比較概要信息的同時就獲得這些詳情的連接，那麼客戶端的開發就比較簡單了，並且也更靈活了。 其實這個描述中還告訴咱們一些分頁的信息，好比每頁20條記錄(size: 20)、總共幾頁（totalPages：1）、總共多少個元素（totalElements: 1）、當前第幾頁（number: 0）。固然你也能夠在發送API請求時，指定page、size或sort參數。好比 http://localhost:8080/todos?page=0&size=10 就是指定每頁10條，當前頁是第一頁（從0開始）。 魔法的背後 這麼簡單就生成一個有數據庫支持的REST API，這件事看起來比較魔幻，但通常這麼魔幻的事情總感受不太託底，除非咱們知道背後的原理是什麼。首先再來回顧一下 TodoRepository 的代碼： @RepositoryRestResource(collectionResourceRel = "todo", path = "todo") public interface TodoRepository extends MongoRepository<Todo, String>{ }

Spring是最先的幾個IoC（控制反轉或者叫DI）框架之一，因此最擅長的就是依賴的注入了。這裏咱們寫了一個Interface，能夠猜到Spring必定是有一個這個接口的實如今運行時注入了進去。若是咱們去 spring-data-mongodb 的源碼中看一下就知道是怎麼回事了，這裏只舉一個小例子，你們能夠去看一下 SimpleMongoRepository.java （ 源碼連接 ），因爲源碼太長，我只截取一部分： public class SimpleMongoRepository<T, ID extends Serializable> implements MongoRepository<T, ID> { private final MongoOperations mongoOperations; private final MongoEntityInformation<T, ID> entityInformation; /**

• Creates a new {@link SimpleMongoRepository} for the given {@link MongoEntityInformation} and {@link MongoTemplate}.
• @param metadata must not be {@literal null}.
• @param mongoOperations must not be {@literal null}. / public SimpleMongoRepository(MongoEntityInformation<T, ID> metadata, MongoOperations mongoOperations) { Assert.notNull(mongoOperations); Assert.notNull(metadata); this.entityInformation = metadata; this.mongoOperations = mongoOperations; } /
• (non-Javadoc)
• @see org.springframework.data.repository.CrudRepository#save(java.lang.Object) */ public S save(S entity) { Assert.notNull(entity, "Entity must not be null!"); if (entityInformation.isNew(entity)) { mongoOperations.insert(entity, entityInformation.getCollectionName()); } else { mongoOperations.save(entity, entityInformation.getCollectionName()); } return entity; } ... public T findOne(ID id) { Assert.notNull(id, "The given id must not be null!"); return mongoOperations.findById(id, entityInformation.getJavaType(), entityInformation.getCollectionName()); } private Query getIdQuery(Object id) { return new Query(getIdCriteria(id)); } private Criteria getIdCriteria(Object id) { return where(entityInformation.getIdAttribute()).is(id); } ... }

也就是說其實在運行時Spring將這個類或者其餘具體接口的實現類注入了應用。這個類中有支持各類數據庫的操做。我瞭解到這步就以爲ok了，有興趣的同窗能夠繼續深刻研究。 雖然不想在具體類上繼續研究，但咱們仍是應該多瞭解一些關於 MongoRepository 的東西。這個接口繼承了 PagingAndSortingRepository （定義了排序和分頁） 和 QueryByExampleExecutor。而 PagingAndSortingRepository 又繼承了 CrudRepository （定義了增刪改查等）。 第二個魔法就是 @RepositoryRestResource(collectionResourceRel = "todo", path = "todo") 這個元數據的修飾了，它直接對MongoDB中的集合（本例中的todo）映射到了一個REST URI（todo）。所以咱們連Controller都沒寫就把API搞出來了，並且仍是個Hypermedia REST。 其實呢，這個第二個魔法只在你須要變動映射路徑時須要。本例中若是咱們不加 @RepositoryRestResource 這個修飾符的話，一樣也能夠生成API，只不過其路徑按照默認的方式變成了 todoes ，你們能夠試試把這個元數據修飾去掉，而後重啓服務，訪問 http://localhost:8080/todoes 看看。 說到這裏，順便說一下REST的一些約定俗成的規矩。通常來講若是咱們定義了一個領域對象 （好比咱們這裏的Todo），那麼這個對象的集合（好比Todo的列表）可使用這個對象的命名的複數方式定義其資源URL，也就是剛剛咱們訪問的 http://localhost:8080/todoes，對於新增一個對象的操做也是這個URL，但Request的方法是POST。 而這個某個指定的對象（好比指定了某個ID的Todo）可使用 todoes/:id 來訪問，好比本例中 http://localhost:8080/todoes/588a01abc5d0e23873d4c1b8。對於這個對象的修改和刪除使用的也是這個URL，只不過HTTP Request的方法變成了PUT（或者PATCH）和DELETE。 這個裏面默認採用的這個命名 todoes 是根據英語的語法來的，通常來講複數是加s便可，但這個todo，是輔音+o結尾，因此採用的加es方式。 todo 其實並非一個真正意義上的單詞，因此我認爲更合理的命名方式應該是 todos。因此咱們仍是改爲 @RepositoryRestResource(collectionResourceRel = "todos", path = "todos") 無招勝有招 剛纔咱們提到的都是開箱即用的一些方法，你可能會想，這些東西看上去很炫，但沒有毛用，實際開發過程當中，咱們要使用的確定不是這麼簡單的增刪改查啊。說的有道理，咱們來試試看非默認方法。那麼咱們就來增長一個需求，咱們能夠經過查詢Todo的描述中的關鍵字來搜索符合的項目。 顯然這個查詢不是默認的操做，那麼這個需求在Spring Boot中怎麼實現呢？很是簡單，只需在 TodoRepository 中添加一個方法： ... public interface TodoRepository extends MongoRepository<Todo, String>{ List findByDescLike(@Param("desc") String desc); }

太難以想象了，這樣就行？不信能夠啓動服務後，在瀏覽器中輸入 http://localhost:8080/todos/search/findByDescLike?desc=swim 去看看結果。是的，咱們甚至都沒有寫這個方法的實現就已經完成了該需求（題外話，其實 http://localhost:8080/todos?desc=swim 這個URL也起做用）。 你說這裏確定有鬼，我贊成。那麼咱們試試把這個方法改個名字 findDescLike ，果真很差用了。爲何呢？這套神奇的療法的背後仍是那個咱們在第一篇時提到的 Convention over configuration，要神奇的療效就得遵循Spring的配方。這個配方就是方法的命名是有講究的：Spring提供了一套能夠經過命名規則進行查詢構建的機制。這套機制會把方法名首先過濾一些關鍵字，好比 find…By, read…By, query…By, count…By 和 get…By 。系統會根據關鍵字將命名解析成2個子語句，第一個 By 是區分這兩個子語句的關鍵詞。這個 By 以前的子語句是查詢子語句（指明返回要查詢的對象），後面的部分是條件子語句。若是直接就是 findBy… 返回的就是定義Respository時指定的領域對象集合（本例中的Todo組成的集合）。 通常到這裏，有的同窗可能會問 find…By, read…By, query…By, get…By 到底有什麼區別啊？答案是。。。木有區別，就是別名，從下面的定義能夠看到這幾個東東其實生成的查詢是同樣的，這種讓你不用查文檔均可以寫對的方式也比較貼近目前流行的天然語言描述風格（相似各類DSL）。 private static final String QUERY_PATTERN = "find|read|get|query|stream";

剛剛咱們實驗了模糊查詢，那若是要是精確查找怎麼作呢，好比咱們要篩選出已完成或未完成的Todo，也很簡單： List findByCompleted(@Param("completed") boolean completed);

嵌套對象的查詢怎麼搞？ 看到這裏你會問，這都是簡單類型，若是複雜類型怎麼辦？嗯，好的，咱們仍是增長一個需求看一下：如今需求是要這個API是多用戶的，每一個用戶看到的Todo都是他們本身建立的項目。咱們新建一個User領域對象： package dev.local.user; import org.springframework.data.annotation.Id; public class User { @Id private String id; private String username; private String email; //此處爲節省篇幅省略屬性的getter和setter } 爲了能夠添加User數據，咱們須要一個User的REST API，因此添加一個 UserRepository package dev.local.user; import org.springframework.data.mongodb.repository.MongoRepository; public interface UserRepository extends MongoRepository<User, String> { }

而後給 Todo 領域對象添加一個User屬性。 package dev.local.todo; //省略import部分 public class Todo { //省略其餘部分 private User user; public User getUser() { return user; } public void setUser(User user) { this.user = user; } } 接下來就能夠來把 TodoRepository 添加一個方法定義了，咱們先實驗一個簡單點的，根據用戶的email來篩選出這個用戶的Todo列表： public interface TodoRepository extends MongoRepository<Todo, String>{ List findByUserEmail(@Param("userEmail") String userEmail); }

如今須要構造一些數據了，你能夠經過剛剛咱們創建的API使用Postman工具來構造：咱們這裏建立了2個用戶，以及一些Todo項目，分別屬於這兩個用戶，並且有部分項目的描述是同樣的。接下來就能夠實驗一下了，咱們在瀏覽器中輸入 http://localhost:8080/todos/search/findByUserEmail?userEmail=peng@gmail.com ，咱們會發現返回的結果中只有這個用戶的Todo項目。 { "_embedded" : { "todos" : [ { "desc" : "go swimming", "completed" : false, "user" : { "username" : "peng", "email" : "peng@gmail.com" }, "_links" : { "self" : { "href" : "http://localhost:8080/todos/58908a92c5d0e2524e24545a" }, "todo" : { "href" : "http://localhost:8080/todos/58908a92c5d0e2524e24545a" } } }, { "desc" : "go for walk", "completed" : false, "user" : { "username" : "peng", "email" : "peng@gmail.com" }, "_links" : { "self" : { "href" : "http://localhost:8080/todos/58908aa1c5d0e2524e24545b" }, "todo" : { "href" : "http://localhost:8080/todos/58908aa1c5d0e2524e24545b" } } }, { "desc" : "have lunch", "completed" : false, "user" : { "username" : "peng", "email" : "peng@gmail.com" }, "_links" : { "self" : { "href" : "http://localhost:8080/todos/58908ab6c5d0e2524e24545c" }, "todo" : { "href" : "http://localhost:8080/todos/58908ab6c5d0e2524e24545c" } } }, { "desc" : "have dinner", "completed" : false, "user" : { "username" : "peng", "email" : "peng@gmail.com" }, "_links" : { "self" : { "href" : "http://localhost:8080/todos/58908abdc5d0e2524e24545d" }, "todo" : { "href" : "http://localhost:8080/todos/58908abdc5d0e2524e24545d" } } } ] }, "_links" : { "self" : { "href" : "http://localhost:8080/todos/search/findByUserEmail?userEmail=peng@gmail.com" } } }

看到結果後咱們來分析這個 findByUserEmail 是如何解析的：首先在 By 以後，解析器會按照 camel （每一個單詞首字母大寫）的規則來分詞。那麼第一個詞是 User，這個屬性在 Todo 中有沒有呢？有的，可是這個屬性是另外一個對象類型，因此緊跟着這個詞的 Email 就要在 User 類中去查找是否有 Email 這個屬性。聰明如你，確定會想到，那若是在 Todo 類中若是還有一個屬性叫 userEmail 怎麼辦？是的，這種狀況下 userEmail 會被優先匹配，此時請使用 _ 來顯性分詞處理這種混淆。也就是說若是咱們的 Todo 類中同時有 user 和 userEmail 兩個屬性的狀況下，咱們若是想要指定的是 user 的 email ，那麼須要寫成 findByUser_Email。 還有一個問題，我估計不少同窗如今已經在想了，那就是咱們的這個例子中並無使用 user 的 id，這不科學啊。是的，之因此沒有在上面使用 findByUserId 是由於要引出一個易錯的地方，下面咱們來試試看，將 TodoRepository 的方法改爲 public interface TodoRepository extends MongoRepository<Todo, String>{ List findByUserId(@Param("userId") String userId); } 你若是打開瀏覽器輸入 http://localhost:8080/todos/search/findByUserId?userId=589089c3c5d0e2524e245458 (這裏的Id請改爲你本身mongodb中的user的id)，你會發現返回的結果是個空數組。緣由是雖然咱們在類中標識 id 爲 String 類型，但對於這種數據庫本身生成維護的字段，它在MongoDB中的類型是ObjectId，因此在咱們的接口定義的查詢函數中應該標識這個參數是 ObjectId。那麼咱們只須要改動 userId 的類型爲 org.bson.types.ObjectId 便可。 package dev.local.todo; import org.bson.types.ObjectId; import org.springframework.data.mongodb.repository.MongoRepository; import org.springframework.data.repository.query.Param; import org.springframework.data.rest.core.annotation.RepositoryRestResource; import java.util.List; @RepositoryRestResource(collectionResourceRel = "todos", path = "todos") public interface TodoRepository extends MongoRepository<Todo, String>{ List findByUserId(@Param("userId") ObjectId userId); }

再複雜一些行不行？ 好吧，到如今我估計還有一大波攻城獅表示不服，實際開發中須要的查詢比上面的要複雜的多，再複雜一些怎麼辦？仍是用例子來講話吧，那麼如今咱們想要模糊搜索指定用戶的Todo中描述的關鍵字，返回匹配的集合。這個需求咱們只需改動一行，這個以命名規則爲基礎的查詢條件是能夠加 And、Or 這種關聯多個條件的關鍵字的。 List findByUserIdAndDescLike(@Param("userId") ObjectId userId, @Param("desc") String desc);

固然，還有其餘操做符：Between (值在二者之間), LessThan (小於), GreaterThan （大於）, Like （包含）, IgnoreCase （b忽略大小寫）, AllIgnoreCase （對於多個參數所有忽略大小寫）, OrderBy （引導排序子語句）, Asc （升序，僅在 OrderBy 後有效） 和 Desc （降序，僅在 OrderBy 後有效）。 剛剛咱們談到的都是對於查詢條件子語句的構建，其實在 By 以前，對於要查詢的對象也能夠有限定的修飾詞 Distinct （去重，若有重複取一個值）。好比有可能返回的結果有重複的記錄，可使用 findDistinctTodoByUserIdAndDescLike。 我能夠直接寫查詢語句嗎？幾乎全部碼農都會問的問題。固然能夠咯，也是一樣簡單，就是給方法加上一個元數據修飾符 @Query public interface TodoRepository extends MongoRepository<Todo, String>{ @Query("{ 'user._id': ?0, 'desc': { '$regex': ?1} }") List searchTodos(@Param("userId") ObjectId userId, @Param("desc") String desc); }

採用這種方式咱們就不用按照命名規則起方法名了，能夠直接使用MongoDB的查詢進行。上面的例子中有幾個地方須要說明一下 ?0 和 ?1 是參數的佔位符，?0 表示第一個參數，也就是 userId；?1 表示第二個參數也就是 desc。 使用user._id 而不是 user.id 是由於全部被 @Id 修飾的屬性在Spring Data中都會被轉換成 _id MongoDB中沒有關係型數據庫的Like關鍵字，須要以正則表達式的方式達成相似的功能。 其實，這種支持的力度已經可讓咱們寫出相對較複雜的查詢了。但確定仍是不夠的，對於開發人員來說，若是不給能夠自定義的方式基本沒人會用的，由於總有這樣那樣的緣由會致使咱們但願能徹底掌控咱們的查詢或存儲過程。但這個話題展開感受就內容更多了，後面再講吧。 喜歡的點點關注，點點贊。 對Java技術，架構技術感興趣的同窗，歡迎加QQ羣668041364?，一塊兒學習，相互討論。 羣內已經有小夥伴將知識體系整理好（源碼，筆記，PPT，學習視頻），歡迎加羣領取。