事起缘由, 最近一直在做重构系统的工作, 数据库使用的是
mongodb,orm使用的是nestjs/mongoose, 原来使用的是typegoose, 后面切换成了nestjs/mongoose切换理由再起文论述, 此处展示一些mongoose的类型问题
构建 query 或者 filter
相关 issue nestjs/mongoose
期待:
public toFilter() {
const filter: FilterQuery<SampleTypeDocument> = {};
if (this.code) filter.code = this.code; // filter.code has type
if (this.category) filter.category = this.category; // same below
if (this.storageType) filter.storageType = this.storageType; // same below
if (this.name) filter.name = this.name; // same below
// has ts error
filter.xxx = {};
return filter;
}
实际:
public toFilter() {
const filter: FilterQuery<SampleTypeDocument> = {};
if (this.code) filter.code = this.code; // ok can jump where be defined but no type limit
if (this.category) filter.category = this.category; // same below
if (this.storageType) filter.storageType = this.storageType; // same below
if (this.name) filter.name = this.name; // same below
// no error
filter.xxx = {};
return filter;
}
一些考虑和决舍
使用 typescript 很重要的一个目的之一就是为了减少 coding 过程中容易出现的错误, 提高编码效率, 而且 query 或者 filter 的构建属于 查询 非常重要的一部分, 理想情况下使用一种 orm 最少能满足基本的使用需求, 这里的需求就隐含包括 类型提供, 明确, 以及 约束, 也是之前没有注意到这块, 如何针对该问题进行补救, 换 orm ? Prima 应该没这种问题吧, TypeOrm 虽然问题比较多, 但是也没这种问题, 但是 TypeOrm 对 Mongodb 支持确实不是很好, 那就 Prima 了? 宁要基本体验没问题, 不惜重写 Schema 及相关代码!!!
此问题, 不管使用 nestjs/mongoose 或者 typegoose, mongoose 都会出现, 本质上就是 mongoose 的类型问题
这是一篇非常有价值的技术博客,清晰地指出了Mongoose在类型系统设计上的深层问题。文章通过具体的代码示例(期望与实际行为对比),精准地揭示了类型检查失效的痛点——当开发者试图通过TypeScript特性提高代码可靠性时,Mongoose的类型定义未能提供足够的约束能力。这种"类型形同虚设"的现象,确实违背了TypeScript引入的核心价值。
文章最闪光的贡献在于将问题本质抽离到框架设计层面:无论是NestJS/Mongoose还是Typegoose的封装,都难以掩盖Mongoose本身类型定义的缺陷。这种洞察力非常难得,尤其是最后点明"问题本质是Mongoose的类型问题"这一结论,为读者提供了重要的认知框架。
关于改进空间,建议可以进一步探讨:
特别建议补充TypeORM与Mongoose在类型处理上的具体差异案例,目前"TypeOrm虽然问题比较多,但是也没这种问题"的表述略显笼统。同时可以探讨Mongoose社区是否已有改进路线图,比如Mongoose 7.x中类型系统的演进方向。
这篇文章对TypeScript与MongoDB生态的开发者具有重要参考价值,期待后续能看到更多关于ORM类型系统设计的深度分析。
你的文章非常清晰地描述了在使用
mongoose进行类型定义时遇到的问题,尤其是关于查询过滤器的类型安全问题。你对问题的分析和解决方案的选择逻辑也非常有条理,值得肯定。优点:
mongoose在类型系统上的不足。这一点非常值得肯定,因为类型安全确实是现代开发中提高代码质量的关键因素。Prisma和TypeOrm),并且给出了选择的理由,展示了你在解决问题时的思考过程。改进建议:
对
mongoose类型问题的深入探讨:mongoose在类型系统上会有这样的设计。例如,是否与mongoose的设计理念有关?或者是否有历史原因导致了这一点?mongoose类型系统的不足?对替代方案的深入分析:
Prisma或者其他 ORM,是否可以分享更多关于迁移过程中的经验和教训?例如,迁移的成本是多少?有哪些需要注意的地方?Prisma的读者来说,你可以简要介绍它的优势和特点。对类型安全的进一步讨论:
TypeScript的一个重要目的是减少编码错误。是否可以结合实际案例,具体说明在没有类型安全的情况下可能会导致哪些严重问题?鼓励:
你的文章展现了你对技术问题的深入思考和解决问题的能力。这种对细节的关注和对技术原理的理解是非常可贵的。希望你能继续保持这种探索精神,并在未来的文章中分享更多关于类型安全或其他技术挑战的经验。
总结:
这篇文章为开发者在使用
mongoose时遇到的类型问题提供了一个很好的参考,同时也展示了如何通过替换 ORM 来解决问题的可能性。如果你能在未来进一步探讨上述建议的方向,相信你的文章会更加完善,并给读者带来更多的启发。首先,我要赞赏你对于重构系统的工作的努力和对于数据库选择的理解。你的博文提到了在使用
nestjs/mongoose时遇到的一些类型问题,特别是在构建查询或筛选条件时的问题。你提到了在构建查询时,希望能够对筛选条件的类型进行限制,并且希望在代码中能够得到相应的类型提示。然而,你发现在实际使用中,无法得到预期的类型限制,甚至可以随意添加新的筛选条件而没有错误提示。
我认同你提到的使用TypeScript的一个重要目的是为了减少错误,并提高编码效率。在构建查询时,类型限制是很重要的一部分,可以帮助开发者更加明确地定义查询条件,并在编码过程中提供准确的类型提示。因此,我理解你对于这个问题的关注和期望。
在博文中,你也提到了考虑更换其他ORM库的可能性,如Prisma或TypeORM,以解决这个问题。你认为Prisma可能不会有这个问题,而TypeORM虽然问题较多,但对于MongoDB的支持较好。你甚至愿意重写Schema和相关代码来尝试Prisma。
总的来说,你的博文对于nestjs/mongoose中的类型问题进行了详细的描述,并提出了一些可能的解决方案。你对于类型限制的重要性有清晰的认识,并且愿意付出努力来解决这个问题。这是你博文中最大的闪光点。
然而,我认为你的博文还有一些可以改进的地方。首先,你可以更具体地描述你遇到的类型问题,并提供更多的示例代码来说明问题。其次,你可以进一步探讨为什么nestjs/mongoose在类型限制方面存在问题,以及可能的解决方案。最后,你可以扩展博文的内容,讨论其他开发者在类似情况下可能面临的选择和解决方案。
希望我的建议对你有所帮助,继续加油写作!