Javascript node.js遵循数据映射器模式的ORM

时间:2022-09-11 13:45:31

I've been working with active record and data mapper implementations of ORM enough to know the problems with using active record implemented ORM in my large projects. Right now I'm thinking to migrate one of my projects to node.js and trying to find the similar tools Im using right now. After research I didn't found any node.js ORM that follows data mapper pattern. They all are active record. Maybe I missing something, and you can tell me is there is a good popular ORM for node.js that doesn't follow active record pattern?

我一直在使用ORM的活动记录和数据映射器实现,足以了解在我的大型项目中使用活动记录实现ORM的问题。现在我正在考虑将我的一个项目迁移到node.js并尝试找到我现在正在使用的类似工具。经过研究,我没有发现任何遵循数据映射器模式的node.js ORM。他们都是积极的记录。也许我错过了一些东西,你可以告诉我,对于不遵循活动记录模式的node.js,有一个很好的流行ORM吗?

The libraries Ive looked on:

我看过的图书馆:

3 个解决方案

#1


12  

After lot of frustration of currently exist ORMs for JavaScript I have written my own ORM that supports TypeScript / ES6 / ES5 and follows data mapper patterns and all other best practices - TypeORM

在经历了当前存在的用于JavaScript的ORM的许多挫折之后,我编写了自己的ORM,它支持TypeScript / ES6 / ES5,并遵循数据映射器模式和所有其他最佳实践 - TypeORM

#2


1  

I wrote an ORM for Node.js called node-data-mapper; it's available here: https://www.npmjs.com/package/node-data-mapper. It's an ORM for Node.js that uses the data-mapper pattern. The developer uses plain old JavaScript objects when reading from and writing to the database. Relationships between tables are not rigidly defined, which makes joining very flexible--in my opinion, anyway--albeit somewhat verbose. The actual data mapping algorithm is fast and short, and the complexity is linear (the transformation from tabular DB data to a normalized JavaScript object is done in one loop).

我为Node.js编写了一个名为node-data-mapper的ORM;它可以在这里找到:https://www.npmjs.com/package/node-data-mapper。这是使用数据映射器模式的Node.js的ORM。开发人员在读取和写入数据库时​​使用普通的旧JavaScript对象。表之间的关系没有严格定义,这使得加入非常灵活 - 我认为,无论如何 - 虽然有点冗长。实际的数据映射算法快速而简短,复杂性是线性的(从表格DB数据到规范化JavaScript对象的转换是在一个循环中完成的)。

I also did my best to make it fairly fault tolerant. There's 100% code coverage and, while I know that doesn't prove the absence of defects, I did try to test as thoroughly as possible.

我也尽力使其具有相当的容错能力。有100%的代码覆盖率,虽然我知道并没有证明没有缺陷,但我确实尝试尽可能彻底地进行测试。

I modeled the interface very loosely after Doctrine 1. (I've used LINQ, Doctrine 1 and 2, and Hibernate fairly extensively, and of those ORMs I like the interface for Doctrine 1 the best. node-data-mapper is not a JavaScript port of Doctrine by any means, though, and the interface is significantly different.) The query interface returns promises using the deferred module.

我在Doctrine 1之后非常宽松地对接口进行了建模。(我已经使用了LINQ,Doctrine 1和2,以及Hibernate相当广泛,而那些ORM我最喜欢Doctrine 1的接口.node-data-mapper不是JavaScript但是,任何方式的Doctrine端口都是明显不同的。)查询接口使用延迟模块返回promises。

I modeled the conditions (e.g. WHERE and ON clauses) after MongoDB's conditions. Hopefully that makes the conditions somewhat intuitive while providing a way for making reusable queries (specifically, complex SELECT queries that can be filtered securely in many different ways). The conditions are treated as a domain-specific language, and are lexed, parsed, and compiled.

我在MongoDB的条件之后建模了条件(例如WHERE和ON子句)。希望这使得条件有点直观,同时提供了一种制作可重用查询的方法(特别是可以以多种不同方式安全过滤的复杂SELECT查询)。这些条件被视为特定于域的语言,并被排除,解析和编译。

Anyway, the module is something that I use in my personal projects, but I'd love to get some feedback from other developers in the community! I tried to provide plenty of examples to get people up and running quickly. Currently the module supports MySQL only, but I'm working on adding support for MSSQL.

无论如何,这个模块是我在个人项目中使用的东西,但我很乐意从社区中的其他开发者那里获得一些反馈!我试图提供大量的例子来让人们快速上手。目前该模块仅支持MySQL,但我正在努力增加对MSSQL的支持。

#3


-5  

The distinction between data-mapper pattern and active record doesn't really make sense in the dynamic language such as JavaScript. Typically data mapper is more lightweight in typed language, but in JS it does not really make a difference. From the top of my head, I can mention two very popular projects which you probably don't know:

数据映射器模式和活动记录之间的区别在JavaScript等动态语言中并没有真正意义。通常,数据映射器在类型语言中更轻量级,但在JS中它并没有真正有所作为。从我的头脑中,我可以提到两个非常受欢迎的项目,你可能不知道:

Waterline.js is a Sails abstraction, which works quite well on top of many database systems.

Waterline.js是一个Sails抽象,它在许多数据库系统上运行良好。

If you would consider MongoDB for your DB - Mongoose.js.

如果您将MongoDB视为您的数据库 - Mongoose.js。

#1


12  

After lot of frustration of currently exist ORMs for JavaScript I have written my own ORM that supports TypeScript / ES6 / ES5 and follows data mapper patterns and all other best practices - TypeORM

在经历了当前存在的用于JavaScript的ORM的许多挫折之后,我编写了自己的ORM,它支持TypeScript / ES6 / ES5,并遵循数据映射器模式和所有其他最佳实践 - TypeORM

#2


1  

I wrote an ORM for Node.js called node-data-mapper; it's available here: https://www.npmjs.com/package/node-data-mapper. It's an ORM for Node.js that uses the data-mapper pattern. The developer uses plain old JavaScript objects when reading from and writing to the database. Relationships between tables are not rigidly defined, which makes joining very flexible--in my opinion, anyway--albeit somewhat verbose. The actual data mapping algorithm is fast and short, and the complexity is linear (the transformation from tabular DB data to a normalized JavaScript object is done in one loop).

我为Node.js编写了一个名为node-data-mapper的ORM;它可以在这里找到:https://www.npmjs.com/package/node-data-mapper。这是使用数据映射器模式的Node.js的ORM。开发人员在读取和写入数据库时​​使用普通的旧JavaScript对象。表之间的关系没有严格定义,这使得加入非常灵活 - 我认为,无论如何 - 虽然有点冗长。实际的数据映射算法快速而简短,复杂性是线性的(从表格DB数据到规范化JavaScript对象的转换是在一个循环中完成的)。

I also did my best to make it fairly fault tolerant. There's 100% code coverage and, while I know that doesn't prove the absence of defects, I did try to test as thoroughly as possible.

我也尽力使其具有相当的容错能力。有100%的代码覆盖率,虽然我知道并没有证明没有缺陷,但我确实尝试尽可能彻底地进行测试。

I modeled the interface very loosely after Doctrine 1. (I've used LINQ, Doctrine 1 and 2, and Hibernate fairly extensively, and of those ORMs I like the interface for Doctrine 1 the best. node-data-mapper is not a JavaScript port of Doctrine by any means, though, and the interface is significantly different.) The query interface returns promises using the deferred module.

我在Doctrine 1之后非常宽松地对接口进行了建模。(我已经使用了LINQ,Doctrine 1和2,以及Hibernate相当广泛,而那些ORM我最喜欢Doctrine 1的接口.node-data-mapper不是JavaScript但是,任何方式的Doctrine端口都是明显不同的。)查询接口使用延迟模块返回promises。

I modeled the conditions (e.g. WHERE and ON clauses) after MongoDB's conditions. Hopefully that makes the conditions somewhat intuitive while providing a way for making reusable queries (specifically, complex SELECT queries that can be filtered securely in many different ways). The conditions are treated as a domain-specific language, and are lexed, parsed, and compiled.

我在MongoDB的条件之后建模了条件(例如WHERE和ON子句)。希望这使得条件有点直观,同时提供了一种制作可重用查询的方法(特别是可以以多种不同方式安全过滤的复杂SELECT查询)。这些条件被视为特定于域的语言,并被排除,解析和编译。

Anyway, the module is something that I use in my personal projects, but I'd love to get some feedback from other developers in the community! I tried to provide plenty of examples to get people up and running quickly. Currently the module supports MySQL only, but I'm working on adding support for MSSQL.

无论如何,这个模块是我在个人项目中使用的东西,但我很乐意从社区中的其他开发者那里获得一些反馈!我试图提供大量的例子来让人们快速上手。目前该模块仅支持MySQL,但我正在努力增加对MSSQL的支持。

#3


-5  

The distinction between data-mapper pattern and active record doesn't really make sense in the dynamic language such as JavaScript. Typically data mapper is more lightweight in typed language, but in JS it does not really make a difference. From the top of my head, I can mention two very popular projects which you probably don't know:

数据映射器模式和活动记录之间的区别在JavaScript等动态语言中并没有真正意义。通常,数据映射器在类型语言中更轻量级,但在JS中它并没有真正有所作为。从我的头脑中,我可以提到两个非常受欢迎的项目,你可能不知道:

Waterline.js is a Sails abstraction, which works quite well on top of many database systems.

Waterline.js是一个Sails抽象,它在许多数据库系统上运行良好。

If you would consider MongoDB for your DB - Mongoose.js.

如果您将MongoDB视为您的数据库 - Mongoose.js。