DEV Community
·
代码异味 301 - 数据库作为参数
💡
原文英文，约800词，阅读约需3分钟。
📝
内容提要
为了保持业务逻辑清晰、简化测试并维护领域与基础设施的适当分离，避免将数据库作为参数传递给业务对象。
🎯
关键要点
- 避免将数据库作为参数传递给业务对象，以保持业务逻辑清晰。
- 将数据访问与核心业务行为分开，避免意外耦合。
- 混合责任会导致紧耦合和业务逻辑污染。
- 使用依赖注入而不是仓库模式，寻找真正的抽象。
- 业务对象应专注于核心业务规则，而不是数据存储或检索的逻辑。
- 直接传递数据库会使单元测试变得困难。
- 业务对象应建模真实世界的实体和行为，而不应了解存储机制。
- 避免将数据库作为参数传递可以保持业务逻辑的整洁，简化测试，并维护领域与基础设施的适当分离。
❓
延伸问答
为什么不应该将数据库作为参数传递给业务对象？
将数据库作为参数传递会导致意外耦合，破坏业务逻辑的封装性，增加代码的复杂性和测试难度。
如何保持业务逻辑与数据访问的分离？
可以使用依赖注入而不是仓库模式，确保业务对象专注于核心业务规则，而不涉及数据存储或检索的逻辑。
将数据库直接传递给业务对象会导致哪些问题？
这会导致紧耦合、混合责任、业务逻辑污染和测试困难等问题。
什么是依赖注入，它如何帮助改善代码结构？
依赖注入是一种设计模式，可以将依赖关系从业务对象中分离出来，从而提高代码的可测试性和可维护性。
如何识别代码中的数据库耦合问题？
可以通过检查方法签名是否接受数据库相关对象或SQL语句与业务逻辑混合来识别这些问题。
避免将数据库作为参数传递的最终结论是什么？
避免这种做法可以保持业务逻辑的整洁，简化测试，并维护领域与基础设施的适当分离。
➡️
