Node.js 를 사용 하여 ORM 을 실현 하 는 사고 에 대한 상세 한 설명(그림)

ORM 은 O 와 R 의 매 핑 이다.O 는 대상 을 대상 으로 하고 R 은 관계 형 데이터 베 이 스 를 대표 한다.양 자 는 비슷 한 점도 있 고 특색 도 있다.바로 이런 옳 고 그 름 의 상황 때문에 비 추 는 것 이 필요 하 다.
이상 적 인 상황 은 관계 형 데이터베이스(업무 수요 포함)의 특징 에 따라 데이터 베 이 스 를 설계 하 는 것 이다.또한 대상(업무 수요 포함)의 특징 에 따라 모델(실체 류)을 디자인 한다.그리고 어떻게 비 추 는 지 생각해 보 세 요.하지만 이상 은 뼈 에 사무 친다.
ORM 이 이렇게 하 는 것 도 보지 못 했 고 고수 가 이렇게 디자인 하 는 것 도 보지 못 했다.그렇다면 실제 상황 은 어떤 모습 일 까?.net 의 Entity Framework 를 예 로 들 면.
DB frist 는 먼저 데이터 베 이 스 를 설계 한 다음 에 창고 의 표,메 인 키 등에 따라 실체 류 를 자동 으로 만 드 는 것 이다.그리고 LinQToSQL 을 통 해 조작 할 수 있 습 니 다.이렇게 만들어 진 실체 류 는 분명히 대상 에 대한 특색 이 부족 하 다.
Code frist 는 먼저 실체 류 를 설계 한 다음 에 실체 류 와 특성 에 따라 표 와 메 인 키,제약 등 을 자동 으로 만 드 는 것 이다.그리고 엄밀 하기 위해 실체 류 를 정의 할 때 메 인 키 등 관계 형 특색 을 가 진 동 동 을 설명해 야 한다.
아래 그림

지금 은 node 로 엔진 을 만 들 고 싶 습 니 다.방금 node 를 만 났 는데 이미 만들어 진 orm 이 있 을 거 예요.어떻게 하 는 지 모 르 겠 어 요.일단 그들 을 내 버 려 두 고 자신의 생각 을 밝 히 고 얘 기 하 세 요.네.
왜 node 를 선택해 야 합 니까?그의 원생 이 제 이 슨 을 지지 하 는 줄 알 았 다.제 이 슨 은 프론트 에 홈 구장 이 었 고 js 원생 은 제 이 슨 을 지 원 했 으 며 각종 조작 이 유창 하고 편안 했다.그러나 제 이 슨 은 백 엔 드(C\#)에 도착 하면 번 거 로 워 집 니 다.C\#원생 은 제 이 슨 을 지원 하지 않 고 문자열 이나 실체 류 의 직렬 화 형태 로 만 사용 할 수 있 습 니 다.이것 은 이리 저리 돌아 다 녀 야 하 는데,매우 번거롭다.
node 를 사용 하면 백 엔 드 도 js 로 인 코딩 할 수 있 습 니 다.즉,제 이 슨 을 원생 으로 지원 한 다 는 것 입 니 다.훨씬 편 해 졌어.생각해 보 니 전단 에 json(실체 류)을 만 든 다음 에 전체 가 백 엔 드 에 제출 되 고 백 엔 드 는 json 을 받 아 직접 처리(안전 검증,업무 처리)한 다음 에 직접 지속 된다.시원 하 죠?
node 를 사용 하면 또 하나의 장점 이 있 습 니 다.그것 은 바로 그 가 실행 할 때 실체 류 의 속성 을 정의 할 수 있 습 니 다.예 를 들 어 속성 을 증가 하 는 것 입 니 다.이것 은 C\#에서 실현 할 수 없다.
왜 꼭 실행 해 야 할 때 실체 류 를 수정 할 수 있 습 니까?이렇게 하면 실체 류 의 폭발 을 피 할 수 있 기 때문이다.
항목 을 열 고 몇 개의 실체 클래스 를 정 의 했 는 지 세 어 보 세 요.프로젝트 가 클 수록 실체 류 가 많 지 않 습 니까?변화 가 필요 하고 실체 류 에 속성 을 추가 해 야 할 때 각종 코드 변경 이 필요 하지 않 습 니까?VS 는 많은 일 을 해 줄 수 있 지만
그래서 실행 할 때 실체 류 를 마음대로 수정 하 는 것 이 좋 습 니 다.그러면 코드 수정 문 제 를 크게 피 할 수 있 습 니 다.(코드 가 없 으 니까)
이 편 은 주로 생각 을 말 하기 때문에 먼저 제 이 슨 을 간단하게 디자인 하여 표현 한다.
이 제 이 슨 을 디자인 한 목적 은 엔진 이 제 이 슨 의 상황 에 따라 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?이런 상황 에서 효율 의 차 이 는 매우 크다.
제 생각 은 대상 을 대상 으로 하 는 것 이 아니 라 관계 형 데이터 베 이 스 를 핵심 으로 합 니 다.
실체 류 와 시 계 를 전체적으로 비 추 지 않 고 속성 과 필드 를 비 추 는 것 이다.한 표 의 일부 필드 를 꺼 내 실체 류 로 만들어 조작 한 다 는 것 이다.예 를 들 어 다음 상품 의 예.
시계
필드:isxiajia=1
조건:id=1(단 상품 내리 기)  cate=2(분류 에 따라 내리 기)
그리고 update 문 구 를 만 들 면 됩 니 다.
이것 은 독립 된'실체 류'로 이런 종류 에는 상품 의 다른 속성 이 필요 하지 않다.왜냐하면 단지 내리 기 작업 이기 때문이다.또한 조회 조건 도 완전히 개방 되 어 ID 조회 만 하 는 것 이 아니 라 다른 필드 에 따라 조회 할 수 있다.예 를 들 어 분류 필드 등 이다.이렇게 하면 효율 이 향 상 될 수 있다.
총결산
 위 에서 말 한 것 은 소 편 이 여러분 에 게 소개 한 Node.js 를 사용 하여 ORM 을 실현 하 는 사고 에 대한 상세 한 설명 입 니 다.여러분 에 게 도움 이 되 기 를 바 랍 니 다.만약 에 궁금 한 점 이 있 으 시 면 저 에 게 메 시 지 를 남 겨 주세요.소 편 은 신속하게 답 해 드 리 겠 습 니 다.여기 서도 저희 사이트 에 대한 여러분 의 지지 에 감 사 드 립 니 다!