数据库含companies与employees表时，应分设DAO还是用单一DAO？

这是个非常经典的DAO层设计问题，我来帮你拆解下两种方案的利弊，以及更合理的选择：

方案1：为每个表创建独立的DAO（companyDAO + employeeDAO） #

这是软件工程中遵循单一职责原则的标准做法，优势非常明显：

• 职责清晰：每个DAO只专注于对应表的CRUD操作，新人接手项目时一眼就能明白哪个DAO管什么业务，不需要在一个大文件里翻找半天
• 易于维护：如果需要修改companies表的查询逻辑，直接在companyDAO里调整就行，完全不会影响到employees表的代码，避免了牵一发而动全身的风险
• 扩展性强：后续如果要给某张表加特殊业务方法（比如employeeDAO里加根据部门查员工的方法），直接在对应DAO里新增即可，不会让代码变得臃肿杂乱
• 降低耦合：不同表的操作逻辑完全隔离，不会出现因一处修改导致其他表功能出问题的情况

唯一的“小代价”就是多创建几个类文件，但这在项目可维护性面前完全不值一提。

方案2：单DAO包含所有表的CRUD操作 #

这种做法的弊端远大于所谓的“简便”：

• 违反单一职责：一个DAO类里塞了完全不相关的两张表的操作，会逐渐变成一个臃肿的“上帝类”，代码量越大越难维护
• 职责混乱：时间久了（哪怕是你自己），都可能记混某个方法到底是对应companies还是employees表，排查问题时效率极低
• 耦合度极高：修改某张表的操作逻辑时，很容易误触另一张表的方法，增加了bug出现的概率
• 扩展性差：后续新增表时，只能不断往这个大DAO里加方法，最终会导致这个类变得难以管理，甚至出现重复代码

除非是极端简单的临时小项目（比如只有两张表且永远不会扩展），否则完全不推荐这种做法。

最终结论 #

强烈建议为companies和employees分别创建独立的companyDAO和employeeDAO，这是行业内的通用最佳实践，能让你的代码结构更清晰，后期维护、扩展都更轻松。

内容的提问来源于stack exchange，提问作者ar.thewaterfall