后端開發中的分層架構如何正確劃分業務邏輯和非業務邏輯？

后端分層架構：巧妙劃分業務邏輯與非業務邏輯

后端開發中，分層架構（例如，Controller、Service、DAO三層）至關重要。雖然分層原則清晰，但在實踐中，特別是Service層和DAO層間的界限，以及引入Manager層后的邏輯劃分，常常令人困惑。本文將探討如何有效區分業務邏輯和非業務邏輯。

業務邏輯與非業務邏輯的界定

業務邏輯直接關聯業務需求，用戶可感知；而非業務邏輯則為底層操作，與業務流程無關，例如數據庫操作細節或密碼加密。

以下是一些非業務邏輯示例：

1. 數據庫操作細節： UserManager.delete() 和 DepartmentManager.delete() 可能同時刪除關聯表（例如userdeptmodel）中的數據。這屬于非業務邏輯，因為它只涉及數據庫操作，而非業務流程本身。如果沒有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)  # 假設salt函數用于密碼加鹽       def save(self):          passwd = self.make_password(passwd)          self.passwd = passwd          super().save() #假設super().save()是數據庫保存方法

3. DAO層方法命名： get_super_user 這樣的方法名是否合適，取決于其是否涉及業務邏輯。如果super與業務無關，則可以使用；否則，應在Service層處理。

4. http請求封裝： 后端依賴的封裝，可以放在DAO層，而非Service層。

python中實現類似django Filter的功能

在Django/flask中，數據過濾相對容易。但在Python的三層架構中，需要考慮如何在DAO層處理請求參數。如果沒有spring之類的依賴注入框架，則需手動傳遞參數。 Java中，hibernate等ORM框架提供了強大的數據過濾和查詢功能。

數據實體與分層架構

數據實體用于數據持久化。在三層架構中，Controller、Service和DAO層并非嚴格一一對應。Service層可能調用多個DAO完成一個業務操作，而一個DAO也可能被多個Service調用。

總之，正確區分業務邏輯和非業務邏輯是后端開發的關鍵，合理的分層架構能提升代碼可讀性和可維護性。