后端分層架構(gòu)：業(yè)務(wù)邏輯與非業(yè)務(wù)邏輯的清晰界限
后端開發(fā)中，常見的controller、service和dao三層架構(gòu)并非總是足夠清晰。本文探討如何在service和dao層，甚至引入manager層后，有效區(qū)分業(yè)務(wù)邏輯與非業(yè)務(wù)邏輯，從而構(gòu)建更合理的分層設(shè)計。
業(yè)務(wù)邏輯與非業(yè)務(wù)邏輯的界定
業(yè)務(wù)邏輯直接關(guān)聯(lián)業(yè)務(wù)需求，而非業(yè)務(wù)邏輯則負責(zé)底層操作，例如數(shù)據(jù)訪問、數(shù)據(jù)校驗等。兩者界限模糊常常導(dǎo)致代碼混亂。
-
數(shù)據(jù)操作的封裝: 例如，UserManager.delete() 和 DepartmentManager.delete() 可能同時處理 UserDeptModel 的關(guān)聯(lián)刪除。這屬于非業(yè)務(wù)邏輯，因為它關(guān)注數(shù)據(jù)一致性而非業(yè)務(wù)流程本身。 代碼示例：
class UserManager: def delete(self, user_id): self.user_dao.delete(user_id) self.user_dept_dao.delete_by_user_id(user_id) class DepartmentManager: def delete(self, dept_id): self.dept_dao.delete(dept_id) self.user_dept_dao.delete_by_dept_id(dept_id)
-
數(shù)據(jù)安全處理: 密碼加鹽等操作通常在dao或manager層執(zhí)行，因為這是數(shù)據(jù)保護機制，而非業(yè)務(wù)邏輯。 代碼示例 (python with hypothetical salt function):
class UserDao: def save(self, user): user.password = self.salt(user.password) # ... save user to database ... def salt(self, password): # ... password salting logic ... return salted_password
-
DAO層方法命名規(guī)范: DAO層方法名應(yīng)避免包含業(yè)務(wù)含義。例如，get_super_user() 不如 get_user_by_type(“super”) 清晰。
-
外部服務(wù)調(diào)用封裝: 如果后端依賴外部服務(wù)，應(yīng)在DAO層封裝這些調(diào)用，而非service層，因為這屬于數(shù)據(jù)訪問，而非業(yè)務(wù)邏輯。
模擬django Filter功能
在Python中，如果沒有依賴注入框架，模擬Django filter需要在DAO層處理請求參數(shù)，并逐層傳遞。 Java的spring框架則簡化了這一過程。
數(shù)據(jù)實體與分層關(guān)系
Controller、service和dao并非一一對應(yīng)。其職責(zé)如下：
- Controller: 系統(tǒng)入口，接收和處理請求，保持輕量級。
- Service: 核心業(yè)務(wù)邏輯處理層，相對復(fù)雜。
- DAO: 數(shù)據(jù)訪問層，只負責(zé)數(shù)據(jù)交互，不包含業(yè)務(wù)邏輯。
例如，“創(chuàng)建用戶”業(yè)務(wù)：Service層執(zhí)行“檢查用戶名是否重復(fù)”和“創(chuàng)建用戶”；DAO層提供“根據(jù)用戶名查詢用戶”和“保存用戶”方法。
通過清晰區(qū)分業(yè)務(wù)邏輯和非業(yè)務(wù)邏輯，并遵循合理的分層設(shè)計，可以提高代碼的可維護性和可擴展性。
