Node.js를 사용하여 ORM을 구현하는 아이디어

ORM은 O와 R의 매핑입니다. O는 객체지향, R은 관계형 데이터베이스를 의미합니다. 이 둘은 유사점도 있지만 고유한 특성도 있습니다. 매핑이 필요한 것은 바로 이러한 옳고 그름의 상황 때문이다. 이 글은 주로 Node.js를 사용하여 ORM을 구현하는 아이디어에 대한 자세한 설명(그림 및 텍스트)을 소개합니다. 필요한 친구들이 참고하면 도움이 될 것입니다.

　이상적인 상황은 관계형 데이터베이스의 특성(비즈니스 요구 사항 포함)에 따라 데이터베이스를 설계하는 것입니다. 동시에 모델(엔터티 클래스)은 객체 지향의 특성(비즈니스 요구 사항 포함)에 따라 설계됩니다. 그런 다음 매핑을 수행하는 방법에 대해 생각해 보세요. 그러나 이상은 매우 빈약하고 현실은 너무 풍부하고 충만합니다.

저는 ORM이 이렇게 하는 것을 본 적이 없으며 전문가가 이런 식으로 설계하는 것을 본 적이 없습니다. 그렇다면 실제 상황은 어떤 모습일까요? .net의 Entity Framework를 예로 들어 보겠습니다.

　DB 우선은 데이터베이스를 먼저 설계한 후 라이브러리에 있는 테이블, 기본 키, 외래 키 등을 기반으로 엔터티 클래스를 자동으로 생성하는 것입니다. 그런 다음 LinQToSQL을 통해 작동할 수 있습니다. 이런 방식으로 생성된 엔터티 클래스에는 분명히 객체 지향 기능이 부족합니다.

　코드 프리스트는 엔터티 클래스를 먼저 설계한 후 엔터티 클래스와 특성을 기반으로 테이블, 기본 키 및 외래 키, 제약 조건 등을 자동으로 생성하는 것입니다. 엄격함을 위해 엔터티 클래스를 정의할 때 기본 키 및 외래 키와 같은 관계형 특성을 설명해야 합니다.

아래와 같이

이제 노드를 사용하여 엔진을 만들어 보겠습니다. 방금 node에 접속했는데, 이미 만들어진 ORM이 있는 것 같아요. 어떻게 하는지는 모르겠지만 일단은 제 생각을 명확히 하겠습니다.

노드를 선택해야 하는 이유는 무엇인가요? 기본적으로 json을 지원한다고 생각했습니다. Json은 프론트 엔드의 홈 필드입니다. js는 기본적으로 json을 지원하며 모든 작업이 매우 원활하고 편안합니다. 그러나 json은 백엔드(C#)에 도달하면 문제가 발생합니다. C#은 기본적으로 json을 지원하지 않으며 문자열 또는 엔터티 클래스 직렬화로만 사용할 수 있습니다. 이를 위해서는 이동이 필요하며 이는 매우 번거로운 작업입니다.

　노드를 사용하면 백엔드를 js로 인코딩할 수도 있습니다. 이는 json이 기본적으로 지원된다는 의미입니다. 이것이 훨씬 더 편안합니다. 생각해 보세요. 프런트 엔드는 json(엔티티 클래스)을 생성한 다음 전체를 백 엔드에 제출합니다. 백 엔드는 직접 처리(보안 확인, 비즈니스 처리)를 위해 json을 수신한 다음 직접 유지합니다. 멋지지 않나요!

노드 사용의 또 다른 이점은 속성 추가와 같이 런타임에 엔터티 클래스의 속성을 정의할 수 있다는 것입니다. C#에서는 불가능합니다.

　엔티티 클래스를 런타임에 수정해야 하는 이유는 무엇인가요? 이렇게 하면 엔터티 클래스 수가 폭발적으로 증가하는 것을 피할 수 있기 때문입니다.

　프로젝트를 열고 얼마나 많은 엔터티 클래스가 정의되어 있는지 계산해 보세요. 프로젝트가 클수록 엔터티 클래스가 더 많아지나요? 요구 사항이 변경되어 엔터티 클래스에 속성을 추가해야 하는 경우 다양한 방법으로 코드를 변경해야 합니까? VS는 우리가 많은 작업을 수행하는 데 도움이 될 수 있습니다.

　따라서 런타임 중에 엔터티 클래스를 마음대로 수정하는 것이 더 좋으며, 이렇게 하면 코드 수정 문제를 크게 피할 수 있습니다. (코드가 전혀 없기 때문에)

이번 글은 주로 아이디어에 대한 내용이므로 간단하게 json을 디자인해서 표현해보겠습니다.

　이 json을 설계한 목적은 엔진이 json 상황에 따라 이를 SQL로 연결한 다음 처리를 위해 데이터베이스에 넘겨줄 수 있다는 것입니다.

{
 "operationMode":"add",// add\update\delete\select
 "tableCount":1, //支持多表的级联添加、修改
 "fieldInfo":[{//主表的字段，参与操作的字段，不参与的不用写。第一个字段是主键（不支持多主键）
 "tableName": "t1", //表名。
 "primaryKey":"id",//主键字段名。我不想把主键字段名限制为必须是“ID”
 "_sqlCache": "" ,//缓存的sql语句，每次都拼接sql也挺烦的，弄个缓存存放拼接好的sql。
 "fieldList":{ //涉及到的字段，并不需要把表里的字段都放进来，根据业务需求设计
   //客户端提交的json与之对应
 "field1Name":"field1Value",
 "field2Name":"field2Value"
 }
 },
 { //从表的字段，可以不设置
 "primaryKey": "id", //主键字段名。我不想把主键字段名限制为必须是“ID”
 "foreignKey": "foreignKeyid", //主键字段名。我不想把主键字段名限制为必须是“ID”
 "_sqlCache": "", //缓存的sql语句，每次都拼接sql也挺烦的，弄个缓存存放拼接好的sql。
 "fieldList": { //涉及到的字段（不含外键字段），并不需要把表里的字段都放进来，根据业务需求设计
   //客户端提交的json与之对应
 "field1Name": "field1Value",
 "field2Name": "field2Value"
 }
 } // 从表的字段，参与操作的字段，不参与的不用写。第一个字段是主键，第二个字段是外键
 ],
 "findCol":[{
 "colName":"col1",
 "key1":"abc",
 "key2":"abc", //范围查询时使用，比如从几号到几号
 "findKind":" {colName} like {key}" //查询方式：like、not Like、in、=、between等
 }]
}

일반 ORM은 엔터티 클래스를 핵심으로 사용하며 엔터티 클래스의 무결성을 요구합니다. 즉, 엔터티 클래스는 완전한 테이블에 매핑되어야 합니다. 예를 들어 선반에서 제품을 제거하려는 경우 일반적인 접근 방식은 먼저 데이터베이스에서 제품을 읽고 인스턴스화한 다음 태그 속성(필드)을 수정한 다음 전체 엔터티 클래스를 유지하는 것입니다(다음에 저장). 데이터베이스).

　그런데 SQL은 어떻게 작성하나요? 업데이트만 하면 충분하고, 데이터를 읽을 필요가 없기 때문에 효율성이 다소 떨어지게 됩니다.

　그러면 카테고리의 모든 상품을 삭제하고 싶다면 어떻게 해야 할까요? 이 카테고리의 모든 제품을 버리고 속성 값을 일괄적으로 변경하고 일괄적으로 유지해야 합니다.

　SQL문을 작성한다면? 여전히 동일한 SQL이지만 쿼리 조건이 변경되어 여전히 데이터를 망칠 필요가 없습니다. 이 경우 효율성의 차이는 엄청납니다.

그리고 내 생각은 객체지향이 아닌 관계형 데이터베이스를 기반으로 합니다.

　즉, 엔터티 클래스와 테이블이 전체적으로 매핑되지 않고 속성과 필드가 매핑됩니다. 즉, 테이블에서 일부 필드를 가져와 엔터티 클래스로 만든 다음 작업을 수행합니다. 예를 들어 선반에서 제품을 제거하는 예

Table: Product table

Field: isxiajia = 1

Conditions: id=1(단일 제품이 선반에서 제거됨) cate=2(범주별로 선반에서 제거됨)

그런 다음 업데이트 문을 생성합니다.

　 이는 독립적인 "엔티티 클래스"입니다. 이 클래스는 단지 제거 작업이므로 제품의 다른 속성이 필요하지 않습니다. 또한 쿼리 조건도 완전히 자유화되어 ID 기반 쿼리가 아닌 분류 필드 등 다른 필드 기반 쿼리도 가능합니다. 이러한 방식으로 효율성을 향상시킬 수 있습니다.

관련 권장 사항:

URL 패턴 설정 방법 및 서블릿과 필터의 매핑 규칙

PHP 객체 지향 ID 매핑 소개

주석을 사용한 ORM 매핑 소개

위 내용은 Node.js를 사용하여 ORM을 구현하는 아이디어의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!