問題背景：
??經過在學校的努力學習，2021屆菜鳥畢業嘍。終于踏上了接受社會毒打的歷程，畢業后入職第一家公司，歡天喜地的打開項目準備寫下畢業后的第一套增刪改查，然后emmmmmmm
??公司的項目中，并沒有在學校寫項目時經常使用的實體類，而是統一采用List<Map<String,Object>>這種形式來傳遞參數，而且也沒有使用mybatis，這讓我一個剛進入代碼界的初級開發顯得有點手足無措。好在公司技術大佬給力，對新人也關注到位，給予了充分的時間學習并使用這種開發方式。

隨著增刪改查的日益熟練，也引發了我對這種開發方式的深思：

Java項目中，到底要不要用實體類，用的好處是什么？

??首先想一下，我們為什么要用實體類？
??我想了想，似乎當初在學校學的就是這樣，老師規定：一個實體類對應一個表，方便接收參數，參數檢驗也方便。規范如此，我也就學到了這個。現在想想，當初竟然沒有反問老師一句：為什么把這種開發方式當作規范。
??直到現在，我去問別人，為什么把建實體類當作規范，不寫實體類就是不規范的寫法，多數人給我的回答基本上都是：
??“因為……因為……我的老師就是這么教我的。
??“那為什么你老師認為這樣做是規范？”
??“因為……因為……是我老師的老師這樣教他的。”
??后來，通過各種途徑學習，我了解到，寫實體類其實是為面向對象這個思想服務的，大型項目中，領域建模是必須的，一系列實體構成對一個領域模型的描述和實現,，建模的最直接體現就是實體類，領域和數據庫表不一定一一對應，它是對現實生活中的業務邏輯的翻譯，你能很好的建模，你的項目可擴展性和維護性就越好，也就是所謂的面向對象編程。

??實體類就是一個擁有Set和Get方法的類。實體類通常總是和數據庫之類的(所謂持久層數據)聯系在一起。這種聯系是借由框架(如Hibernate、mybatis)來建立的。
??實體類的定義：
??實體類主要是作為數據管理和業務邏輯處理層面上存在的類別； 它們主要在分析階段區分 實體類的主要職責是存儲和管理系統內部的信息，它也可以有行為，甚至很復雜的行為，但這些行為必須與它所代表的實體對象密切相關。

這段話看起來不太好懂，應該結合實體類的作用來看：
實體類的作用(需要面向對象的一點很基本的知識)：
實體類就是一個載體。
現在的設計差不多都是一張表就等于業務里面的一個類。一條記錄(一般一行數據)是一個對象，一行中的一列就是這個對象的一個屬性。
所以我們在操作某個表時(比如更改這個表的信息)，我們就可以在前臺定義一個這樣的對象，然后將其對應的屬性賦值，然后傳到后臺。
這樣后臺就可以拿到這個對象的所有值了——不用一個一個屬性當參數傳過來，只要傳一個這個類的對象就好了，也就是說只要一個參數就好了。好處不言而喻。
而這種前臺對象到后臺數據庫的聯系，我們是借由框架、配置文件來配置實現的，很方便快捷。并不需要自己手動編程實現。
簡而言之，(大多數情況下)實體類就是數據庫在Java代碼中對應的東東。

??有了實體類，可以更方便的控制屬性的讀寫（有只讀 只寫 和 讀寫）并且可以控制寫的值是否合法（在set的時候進行判斷賦值）以達到對數據操作的有效及安全，其次是為了讓你的程序更方便的調用及操作（你可以將類實例后存在集合內）。
??通過以上的討論，大致可以總結出用實體類的好處：
1. 參數清晰
2. 校驗方便
3. 遵從面向對象思想

再多的暫時還沒總結出來

??那如果沒了實體類，也不用現在流行的mybatis框架，使用List<Map<String,Object>>這種方式傳參呢？
??在學校時一直用java，實體類必寫，即使是很小的一個宿舍管理系統也要強行封裝一層，用實體類CRUD。現在在公司里，越來越感覺到不用的好處。
??首先直接明了的就是，代碼寫起來更加迅速且簡潔了，開發效率真的奇高！
?? java中普遍使用的controller->service->dao->entity的分層方式, 也就是貧血模型

貧血模型，就是一個對象里只有屬性，如java中的pojo，不包含業務代碼

??貧血模型很貌似很經典, 但是寫起來很啰嗦, 如果結合mybatis之類的, 多加幾個mapper層, 實現就變得很復雜. 同時業務邏輯多起來后, 代碼會爆炸.
??公司的這種無實體類，也沒mapper層，自己封裝了一套sql工具類的方式，將代碼極大程度的簡化了，我一直認同：大部分情況下，代碼越少，越容易維護。我把你原來一二十行，分散到五六個類中的代碼，簡化到了兩行代碼搞定，就是這兩行代碼寫的再復雜，讀懂它能有多難？總比你原來五六個類來回跳容易多了吧？況且，這兩行代碼也根本就不復雜，反觀你那一二十行代碼，各種取值轉換，各種循環嵌套。至于拿規范說事的人，一般都是菜雞，不信你問他一句，為什么寫實體類就是規范？不寫實體類就不是規范？他大概率回答不上來。
??另外呢，我公司的業務比較復雜，需求經常來回轉變，一個需求可能過個幾天你都不認識它，不停的變需求意味著你要不停的改變代碼，你就得不停的改變Map，接收Map的類也要不停的變，因為你map的key在不停的變，這時候如果你采用的實體類的方式，代碼反而不好維護，還不如用List<Map<String,Object>>動態的獲取參數來的方便。
??不過，對于開發人員是簡便了，但從整個軟件的參與人員來說，像客戶（或有些BA、產品經理）這些不懂map list這類計算機概念的，溝通起來及其不順暢。
??總的來說，經過兩種開發方式的深度體驗后，不適用實體類的方式在我看來有以下幾個好處：
1. 開發方便
2. 代碼簡潔
3. 約束少，好擴展
4. 容易維護

??不過不用實體類也就要求了開發人員需要對表結構非常熟悉，對業務對象非常熟悉，由于Map里面，key是當變量名來用的，記得有次key敲錯了，找半天，浪費了大量的時間。所以，使用這種方式也就要求了開發人員要對業務非常熟悉，熟悉業務也能更加方便的理清思路嘛。程序員不是機器，有現實可行的邏輯，才能寫出流暢錯誤少的代碼，模型與業務概念一一對應，理解起來快，寫起來也快。
??另外，一個大型項目中這兩種方式多多少少都會有，沒有孰好孰壞，各有各的適用范圍。
??用與不用，也是需要根據項目實際情況來決定，沒有所謂的規范，走的人多了，便有了路，樹之所以為樹，是因為人叫它樹，我們只是在盡可能統一樹的概念而已。
??最后，送給大家一句在思考這個問題過程中看到的話：軟件的生命周期不只是開發。

總結

以上是生活随笔為你收集整理的浅谈Java项目中要不要使用实体类的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。