後端開發中如何區分業務邏輯與存儲邏輯？

後端三層架構：業務邏輯與數據訪問邏輯的界限

後端開發中，常見的controller、service和dao三層架構，在controller和service層的分離相對清晰，主要通過分離業務邏輯和展示邏輯實現，例如將消息隊列(MQ)、HTTP、RPC等與業務邏輯解耦。然而，service層和dao層之間的界限，特別是引入manager層後，常常讓開發者感到困惑。

Python後端開發中，業務邏輯有時會混雜在model層中，例如usermodel.is_super()這樣的業務查詢方法，或usermodel.objects.all()這樣的原生數據庫操作，甚至usermodel.**這樣的跨表操作。

業務邏輯與非業務邏輯的辨析

業務邏輯與非業務邏輯的關鍵在於是否直接關聯客戶需求。客戶無法感知的邏輯通常視為非業務邏輯，包括：

1. 數據庫結構與關聯關係:例如， usermanager.delete()和departmentmanager.delete()方法可以同時處理關聯表（如userdeptmodel ）的刪除，無需在service層分別調用dao層方法兩次。 即使沒有manager層，dao層也可以進行這類關聯或跨表操作，只要這些操作與業務邏輯無關。

    class UserManager:
       def delete(self):
           userdao.delete()
           userdeptdao.delete()
   class DepartmentManager:
       def delete(self):
           departmentdao.delete()
           userdeptdao.delete()

2. 密碼加鹽:用戶只需要知道密碼並非明文存儲，加鹽操作可以在dao或manager層處理。

    class UserDao:
       def make_password(self, passwd):
           return salt(passwd) # 加鹽函數def save(self):
           self.passwd = self.make_password(self.passwd)
           super().save()

3. dao層方法命名與定義: dao層方法命名，例如使用get_super_user這樣的語義化名稱是否合適，取決於其是否與業務邏輯相關。如果super與業務無關，使用get_super_user是可以接受的。

4. HTTP請求封裝:後端依賴（例如其他團隊提供的服務）可以封裝成dao層方法，而非service層方法。

Django/Flask中實現類似Django filter的功能

在Django和Flask中實現類似Django filter的功能時，常常遇到層層穿透的問題，因為dao層需要傳入請求參數。在沒有類似Spring這樣的依賴注入框架的情況下，可以考慮：

• 在Java中，通常使用MyBatis或JPA等框架，通過註解和配置文件管理數據訪問和過濾邏輯。

數據實體與三層架構的關係

數據實體表示系統中的數據對象。在三層架構中，controller、service和dao層並非嚴格一一對應：

• dao層可能包含多個方法處理不同的數據實體，例如userdao和departmentdao 。
• service層可能需要組合多個dao層方法來實現完整的業務邏輯。

總而言之，dao層只負責數據存儲交互，不包含業務邏輯；service層負責執行業務邏輯。例如，創建用戶時，service層檢查用戶名是否重複，然後調用dao層方法保存用戶。 這種架構設計旨在按職責劃分系統，提高代碼的可維護性和可擴展性。

以上是後端開發中如何區分業務邏輯與存儲邏輯？的詳細內容。更多資訊請關注PHP中文網其他相關文章！