1樓：404菌
多建幾個VO(DTO)又沒事，前端要啥字段給啥字段。有些時候前端要的資料會從幾個表裡取。
我所在專案是要求EO(資料庫對應實體類)最上不能出service層，即使沒有改變也得換乙個相同欄位的VO給到ctrl層
2樓：北冥有魚
介面返回的物件屬性一般是等於或多於前端所需的屬性。資料庫中的字段會有一些欄位是介面需要返回的，有乙份是不需要返回，其中不需要返回的部分又有可能是不能返回的，所以需要做一些處理，將返回的資料進行轉換。
其次在業務介面中最好盡可能的避免暴露資料庫的表結構。
處理資料轉換可以在service層，也可以在controller層。看converter層是否有實際的業務含義。有意義靠service層，無意義靠controller層。
簡單點來說，controller的職責就是來處理資料轉化和業務呼叫的。
3樓：Mother Ship
資料庫欄位並不適合全部傳到前端
即使日期數字之類的前端能格式化，判空之類的也能做，但是涉及到許可權的，尤其是涉及到使用者密碼的，你敢往前端傳，介面被人一抓到那就是重大安全事故
資料庫能做搜尋嗎？用資料庫做搜尋的優點和缺點有哪些？
陳廣勝 在網際網路早期，LAMP剛開始大紅大紫的那個時代，許多站點的搜尋就是用資料庫的做的。就是簡單地在要搜尋的字段上加個倒排索引。這麼做的優點是維護和開發簡單，了解點SQL就可以了。不過隨著資料量越來越大，這種做法顯得不是那麼高效。搜尋對於大多數應用來說，不太需要關係型資料庫的一些功能，如事務處理...
資料庫為什麼不提供直接運算元據的介面
已登出 不就是NoSQL那套嗎 靈活性和簡易性 易用性是很難平衡的。比如平時寫個正則都要哭爹叫娘，但你一條條寫規則，寫自動機來parse又繁瑣得要死。所以這個平衡的任務應該交給開發者，由開發者自己編寫CRUD的細節。 許通 朋友，你聽說過 ElasticSearch嗎？安利一下。滑稽 關係型資料庫 ...
每個程式語言都有自己的資料庫抽象介面，那麼ODBC的存在還有意義嗎？
羊牮 如果你自己做了乙個自己格式的資料庫，要實現一種標準介面，你是選擇哪種語言實現介面，還是選擇實現ODBC？毫無疑問是ODBC，因為它是二進位制介面，不需要立足於任何語言，而且任何語言都有它的方式來訪問ODBC。換言之，乙個資料庫成立的那一刻至少要提供乙個ODBC標準的介面，和一套非標準的訪問AP...