Service層抽象規範

2022-05-08 11:51:08 字數 751 閱讀 7109

service層是整個web系統的負責業務邏輯一塊,最有必要實現抽象,service層要達到復用性,低耦合性。那麼該如何抽象呢?一般遵循以下原則

把父類都替換成它的子類,程式的行為沒有變化。簡單地說,子型別必須能夠替換掉它們的父型別。只有當子類可以替換掉父類,軟體單位的功能不受到影響時,父類才能真正被復用,而子類也能夠在父類的基礎上增加新的行為。參見下面的**:

動物* animal = new 狗(); 

animal->吃();

animal->喝();

animal->叫();

如果需求發生變化,需要將「狗」更換成別的動物,只需要更改第一句即可,其它地方無需改變。這就是「面向介面程式設計」的好處。

依賴倒置,其實就是誰也不要依靠誰:除了約定的介面,大家都可以靈活自如。由於有了黎克特制代換原則,才使得開放-封閉成為了可能。依賴倒置,其實可以說是物件導向設計的標誌,用哪種語言來編寫程式不重要,如果編寫時考慮的都是如何針對抽象程式設計而不是針對細節程式設計,即程式中所有的依賴關係都是終止於抽象類或者介面,那就是物件導向的設計,反之就是過程化的設計。

解釋:抽象不應該依賴細節,細節應該依賴抽象。

白話一點:針對介面程式設計,不要對實現程式設計。面向過程開發的問題:為了使得常用**可以復用,通常將常用**寫成函式庫。這就是「高層模組依賴低層模組」。然而在做新專案時,發現業務邏輯的高層模組都是一樣的,但客戶卻希望使用不同的資料庫或儲存資訊方式,導致我們無法復用高層模組(因為它們和底層函式庫綁在一起了)。

controller層和service層的作用

1.在controller和service裡都寫那些 controller,從字面上理解是控制器,所以它是負責業務排程的,所以在這一層應寫一些業務的排程 而具體的業務處理應放在service中去寫,而且service不單純是對於dao的增刪改查的呼叫,service是業務層,所以應該更切近於具體業務...

dao層 service層 事務的理解

dao層 對應資料最底層操作,一般來說,乙個資料庫table對應乙個dao,單錶操作。service層 把客戶多方面要求進行彙總,對外只有引數即可,至於服務層操作多少個dao與客戶無關。事務四大特性 1.原子性 原子性是指事務是乙個不可分割的工作單位,事務中的操作要麼都發生,要麼都不發生。2.一致性...

Service層的效能優化

很多學j2ee方向的同學都接觸過s2sh,即傳統的三大框架,學習這三個經典技術的重點就是挖原理和細節,慢慢地我們就能形成一套思想,以幫助理解其他新框架和新技術。學習技術本身並不難,設計技術方案才是難點,為什麼要這麼設計,這樣設計的哲學依據又在哪?不難發現 struts2中控制層的action是多例的...