若是DAO，Service，Controller返回的數據實體結構一致，咱們該怎麼辦？

若是DAO返回的實體結構，恰好也符合Service想要返回的實體結構，恰好也符合Controller想要返回的實體結構。咱們該怎麼辦？

僅我的觀點

按照較爲規範的開發流程，咱們會經過需求分析出Controller返回實體的結構，根據「下層爲上層服務，以目標爲導向」的原則，設計出Service層返回的實體結構，同理設計出DAO層返回的實體結構。三個實體結構一致，說明咱們只是簡單的返回數據庫數據。

DAO層和Service層的分離是比較完全的，DAO和Service沒有一一對應的關係，DAO具備複用性。DAO層的實體必定是申明在DAO相關包下的（好比com.demo.dao.entity包下）。Service可否直接使用DAO的實體做爲返回呢？

若是使用，則Service的接口抽象和DAO的接口抽象發生了綁定，這意味着，若是DAO的返回實體結構發生了變化，則Service的接口抽象也會跟着發生變化。而DAO和Service是分離的，因此DAO的開發人員不知道也不對Service的此次變化負責。當DAO的抽象發生變化時，Service的開發人員須要判斷新的返回實體是否依然符合Service這個接口的抽象（也就是說，是不是業務的變化致使了這個變化），若是符合，說明業務發生了變化，此時Service接收這個變化，並將變化輻射到了Controller；若是不符合，說明DAO修改後的返回實體已經不符合當前Service接口的要求，此時Service須要申明本身的返回實體，修改此接口的抽象，Controller依然會被變化輻射。

若是Service返回實體不使用DAO返回實體，當DAO返回實體發生變化時，Service開發人員須要關注此次變化，這是他做爲依賴方的必要工做，此時他須要根據業務邏輯判斷，Service的返回是否應該發生變化：若是須要則修改Service返回實體，這就改動了Service的接口抽象，這個變化就會輻射到Controller；若是不須要則Service將會本身消化這個DAO的變化，則這個變化不會輻射到Controller

Controller和Service的狀況同理，結論就是，若是Controller和Service的返回實體發生了綁定，則Service的抽象發生變化必定致使Controller的抽象發生變化，若是不綁定，則Controoler的抽象有可能受影響，有可能不受影響。

可是，有一點和Service不同，Controller的返回值依託的是HTTP協議（大多數狀況下來講是這樣。但有時不是，好比Spring Cloud微服務體系，經過Feign API項目嫁接在一塊兒的兩個項目，雖然在網絡上經過HTTP協議交互，但其實質仍是Java語言層的數據交換），而不是像Service的返回同樣依託編程語言的類型檢查。這意味着，Controller的接口抽象比Service的接口抽象有更寬鬆的自解釋權，Controller更關心你返回的具體數據是什麼，而不是你返回的數據的類型。換句話說，就算變化輻射到了Controller，Controller也擁有較大的自由度，在不改變接口（這個接口指的是Http api）的前提下適應變化。

因此我認爲，在題目所述的狀況下，可使用綁定，綁定能夠減小系統傳遞數據時的內存消耗；避免了開發時寫一堆呆萌的設值代碼。而面對需求變化時，咱們能夠經過增長新接口的方式實現，並不須要經過修改現有接口，若是是數據庫變化這樣的劇烈改動，那系統也只能是忍着疼痛了，由於就算不綁定，DAO層發生的接口抽象的變化，必定會輻射到Service層，Service層卻是有能力吃下這個變化，但每每並不能如願，況且從系統結構的角度來講，Service和Controller是靠的很近的，Controller響應Service的變化，通常不是很吃力的事情。

在使用綁定的狀況下，要注意，不是你本身的返回實體，不要動（註解，註釋，代碼都不能動，由於它不是你的東西）。好比Controller不能由於本身的業務須要改動Service的返回實體結構，Service不能改動DAO的返回實體結構。除了你要明確你所使用的實體你是否能夠改動外，你還要根據整個項目的公約來，假如架構師要求每一個層次的返回實體必須明確區分，那你也只能忘記這篇博客所說的東西，老實的建立本身的實體。最後，博客用從DAO到Controller都同樣的狀況作爲例子描述觀點，但分開來判斷任何相鄰兩層的綁定，都是適用的。