事起缘由, 最近一直在做重构系统的工作, 数据库使用的是
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在类型限制方面存在问题,以及可能的解决方案。最后,你可以扩展博文的内容,讨论其他开发者在类似情况下可能面临的选择和解决方案。
希望我的建议对你有所帮助,继续加油写作!