在MongoDB等NoSQL应用中使用DAO layer是否属于良好实践

你找不到公开的参考示例非常正常，完全不用因此怀疑这个模式的合理性：

• 绝大多数NoSQL的入门教程、快速上手demo为了降低学习门槛，都会跳过分层设计，直接在业务逻辑里调用数据库驱动写查询，这类代码只适合跑通功能的验证场景，根本达不到生产环境的可维护要求。
• 真正落地了规范分层的商业项目代码，极少会完整开源到公开平台，你能搜到的公开示例大多是玩具级项目，自然看不到成熟的DAO层实现。

DAO模式的核心价值从来和底层用什么类型的数据库没有绑定关系，它的本质是实现数据访问逻辑和业务逻辑的彻底解耦：所有和数据存储交互的逻辑——不管是MongoDB的查询语句拼装、聚合管道操作、结果集转领域对象，还是后续要加的缓存读写、多数据源切换、分库分表逻辑——全部收敛到DAO层，上层业务代码只需要调用“按条件查询用户列表”“更新订单状态”这类语义明确的方法，完全不需要感知底层到底用的是MongoDB、MySQL还是别的存储介质。
这种解耦带来的收益在长期迭代的项目里非常明显：后续做查询优化、调整索引、部分数据迁移存储、写单元测试mock数据层的时候，只需要调整DAO层的代码，上层业务逻辑完全不用改动，能少写非常多重复、容易出问题的零散代码。

很多人提到的NoSQL场景下常用的Repository模式，本质就是DAO层的一种框架封装实现：比如Spring Data MongoDB提供的MongoRepository，已经帮你实现了通用的基础CRUD逻辑，你自己写自定义复杂查询、聚合操作的时候，逻辑还是会写在Repository的自定义实现类里，不会散落到Service层，这就是完全标准的DAO设计思路。

当然也不要搞形式主义的硬套：如果是一次性的验证脚本、几十行代码的小工具，怎么写效率高怎么来，没必要强行拆分层加DAO；另外写DAO层的时候不要硬搬关系型数据库时代的过重抽象，比如硬搞一套兼容所有数据库的通用BaseDAO，把MongoDB特有的嵌套查询、聚合管道等特性硬套进关系型的CRUD框架里，那是实现方式走偏了，不是DAO模式本身的问题。

内容的提问来源于stack exchange，提问作者bzal