> 人生要不是大膽地冒險便是一無所獲。——海倫·凱勒 ## MVC中DTO、DO **DTO**（Data Transfer Object）：`數據傳輸對象`，這個概念來源于J2EE的設計模式，原來的目的是為了EJB的分布式應用提供粗粒度的數據實體，以減少分布式調用的次數，從而提高分布式調用的性能和降低網絡負載，但在這里，我泛指用于展示層與服務層之間的數據傳輸對象。 **DO**（Domain Object）：`領域對象`，就是從現實世界中抽象出來的有形或無形的業務實體。 > 當然，在MVC中還有VO、PO等概念。模型歸模型，落地的時候，VO轉DTO、DTO轉DO、DO再轉PO，我想很少有公司嚴格按照這樣的規范來實施的。想要理解其不同，推薦這篇博文閱讀一下——[《DTO與DO的區別大家可能會有個疑問》](https://blog.csdn.net/pyfysf/article/details/106394616)。此處不再展開。 在MVC模型中，DTO與DO的應用時序關系是這樣的：  - Controller與Service數據傳遞使用DTO，DTO作為參數開始執行業務處理。 - 當然，不是Service中的所有方法都會以DTO作為入參。 ## MVC該是什么結構 我相信大家一開始學習JavaWeb的時候，便開始寫MVC了。然而，我也接觸過不少團隊的項目，發現MVC的使用過程中實際看到了兩種模型，如下圖所示：  首先，我想我們先達成一種共識： - Service中引用其他業務的Mapper是一定會存在的。 - Controller中無論如何不允許直接引用Mapper中方法。 - 如果Mapper中取出的結果在多個Service中都需要進行進一步數據處理，那務必在業務Service中對Mapper進行封裝后，再使用到其他業務Service中。 但是，需要注意的是，Mapper一定會有恰當的Service與之匹配，合理的做法是，Service盡量封裝與之業務相關的Mapper方法。 顯然，在某一模型的Service中使用其他模型的Mapper很容易造成代碼模塊混亂。 出現這樣的原因是，開發人員沒有找到側重業務模型的Service中完成業務邏輯的編寫導致的。