새로운 컨텐츠 유형을 작성하는 것보다 새로운 엔티티 유형을 작성하면 어떤 이점이 있습니까?
컨텐트 유형에 CRUD 및 뷰 기능이 모두 내장되어있는 경우 새 엔터티를 만드는 데 필요한 모든 사용자 지정 코딩을 수행하는 것은 다소 과잉입니다.
새로운 컨텐츠 유형을 작성하는 것보다 새로운 엔티티 유형을 작성하면 어떤 이점이 있습니까?
컨텐트 유형에 CRUD 및 뷰 기능이 모두 내장되어있는 경우 새 엔터티를 만드는 데 필요한 모든 사용자 지정 코딩을 수행하는 것은 다소 과잉입니다.
답변:
이점이 무엇인지에 관한 것이 아니라 당신이 말한 특정 상황에 적합한 것에 관한 것입니다. 노드로 거의 모든 것을 나타낼 수 있으며 99 %의 상황에 대해 (최소한 발견 한 것처럼) 사용자 정의 엔티티 유형을 구현할 필요가 없습니다.
나는 항상 taxonomy_term엔티티 유형을 모든 것이 노드 / 콘텐츠 유형이 아닌 이유에 대한 좋은 예 라고 생각 합니다.
분류 용어는 본질적으로 다른 엔티티를 그룹화하기위한 것으로 노드와 동일한 기능을 필요로하지 않습니다. 이론적으로 컨텐츠 유형을 사용하여이 기능 (노드 참조 필드 포함)을 수행 할 수 있지만 분류 용어는 노드와 동일한 기능을 수행 할 필요가 없으므로 실제로는 그렇게 이해되지 않습니다. user및 taxonomy_vocabulary엔티티 유형에 대해서도 동일하게 말할 수 있습니다 .
따라서 분류 용어는 별도의 엔티티로 작성되며 필드를 첨부 할 수있는 등의 이점을 얻는 동시에 필요한 것만 수행하도록 프로그래밍됩니다.
간단한 대답은 노드 / 컨텐트 유형 이 필요한 작업을 수행 하지 않거나 별다른 이익을 얻지 못하는 엄청난 양의 오버 킬 / 오버 헤드 일 때 사용자 지정 엔터티를 작성해야한다는 것입니다.
이것은 내 개인적인 경험에 근거한 것입니다. Drupal 핵심 개발에 직접 참여한 사람이 이에 대해 말한 것을 듣고 싶습니다.
내가 사용하는 매우 간단한 경험 법칙은 귀하의 콘텐츠를 공개적으로 표시해야하는지 여부입니다. 그렇다면 엔티티를 선택하지 않으면 노드로 이동하십시오. Entityforms를 사용하면 엔티티를 채우는 인터페이스를 작성할 수 있습니다.
예를 들어 D6으로 만든 웹 사이트에서 광고 콘텐츠 유형 (이미지 필드, 시작 / 종료 표시 날짜 ...)을 작성하지만 기본적으로 게시하지 않도록 하고 편집자에게 편집 권한을 부여해야합니다. 이 노드를 / view하고 외부 세계에 뷰 / 검색이 표시되지 않기를 바랐습니다. 꽤 번거롭고 엔티티를 다루기가 더 쉬울 것입니다.
엔터티는 특정 사용 사례를 나타냅니다 .
이 간단한 정의에 대한 크레딧은 Fago 로 간다고 생각 하지만 참조를 찾기 위해 게으르다.
원하는 경우 모든 사용 사례에 Content(일명 Nodes)을 사용할 수 있지만 종종 의미가 없습니다.
Content 댓글과 메뉴 위치에 대한 작성자 및 설정이 있습니다.
Users, 위 Content의 user어느 것도 의미가 없기 때문에 사용 사례와 충분히 다른 유스 케이스를 나타내십시오. 반면에 user전자 우편과 암호 가 있어야합니다.
Taxonomy terms 그것들은 계층 구조, 심지어 원형 구조로 배열되는 내장 기능을 가지고 있기 때문에 눈에.니다.
사용 사례가 기존 엔티티와 충분히 유사하면 해당 엔티티를 사용하십시오. 엔티티가 기존 규칙과 크게 다른 규칙으로 관리되는 경우 새 규칙을 작성하십시오.
엔터티 소개 도 있지만 불행히도 실제로 귀하의 질문에 대답하지는 않습니다.
엔티티는 엔티티가 갖는 모든 기능을 가질 필요가 없기 때문에 노드보다 적은 오버 헤드로 엔티티를 작성할 수 있습니다.
또한 스토리지가 더 단순해질 수 있음을 의미합니다. 원하는 경우 JOINS없이 간단한 쿼리로 모든 정보를 가져 오도록 구성 할 수 있습니다. 단 하나의 깔끔한 테이블에 모든 필드가 멋지게 들어 있습니다.
엔터티에 대한 쿼리를 수행해야하는 많은 기능이 있고 데이터베이스에 대한 UPDATE 쿼리와 동시에 많은 엔터티를 업데이트하는 경우 이는 큰 이점이 될 수 있습니다. 단일 테이블에 데이터가 비교적 독립적으로 포함되어 있는지 확인하면 데이터 손상 가능성이 줄어 듭니다.
콘텐츠 유형은 사이트 콘텐츠로 설계되었습니다. 즉, 각 콘텐츠 유형은 사이트에 게시 및 표시되도록 설계되었습니다. 예를 들어 기사 (제외)는 첫 페이지에 표시되도록 설계되었습니다.
이제 고용 또는 아파트 신청서와 같은 것을 만들고 싶다고 가정 해 봅시다. 분명히, 당신은 당신의 웹 사이트에 누군가의 고용 응용 프로그램을 게시하고 싶지 않을 것입니다. 또한 고객 / 리드 연락처 목록을 작성하려면 어떻게해야합니까? 귀하의 웹 사이트에이 정보가 실수로 게시 될 가능성이 있습니까? 개인적으로는 그렇지 않습니다.
따라서, 위에서 논의 된 엔티티 양식 모듈. 컨텐츠가 아닌 엔티티 유형을 작성할 수 있습니다. 그러나 이러한 엔티티 유형은 규칙,보기 및 유기 그룹과 같은 엔티티를 지원하는 모든 모듈에서 사용할 수 있습니다.
그런 다음 제품이 엔티티 유형 인 Drupal Commerce로 들어갑니다. 기본적으로 엔터티를 통해 개발자는 원래 Drupal 디자이너가 예측할 수없는 방식으로 Drupal을 확장 할 수 있습니다.
이것은 논의의 대상이되고 결국 개발자로서 결정을 내려야합니다.
데이터를 자신의 URL로 공개적으로 사용할 수 없어야 할 때마다 노드 대신 엔티티를 선택합니다. 노드는 기본적으로 URL 별명, 게시 된 상태, 제목, 메타 태그 등을 받고 있지만 엔티티는 데이터베이스에서 레코드를 가져옵니다.
"가능한 한 많은 텍스트를 배너에 추가 한 다음 블로그 포스트에서 그중 하나를 선택하고 싶습니다"
엔터티 대 콘텐츠
엔터티 에는 필드 가있는 엔터티 번들 이 있습니다.
콘텐츠는 엔터티 유형입니다. 그래서,
컨텐츠 에는 필드 (본문, 기사 이미지) 가있는 컨텐츠 번들 (문서, 페이지)이 있습니다.
프로그래머라면 반드시 자신의 엔티티를 만드는 경로를 선택하지만 사이트 빌더에게는 가장 적합한 경로가 아닐 수 있습니다. 사이트 빌더를 위해 다시 엔티티를 작성하기위한 UI가 있습니다. http://drupal.org/project/eck