1 년 후, 내 고객들은 본사가 그렇게 말했기 때문에 비교적 복잡한 인트라넷 포털 서비스 (스케줄링, 실제 추적 및보고 등)를 Drupal로 포팅하려고합니다. 이것이 올바른 기술적 선택인지를 결정하기 위해 거의 노력을 기울이지 않았으며 그것이 내 고객이나 심지어 상사들의 통제를 넘어서는 것입니다.
현재 포털은 리팩토링되는 프로세스에서 가장 혐오스럽고 가장 비용 효율적인 계획은 Doctrine 2를 통해 도메인 모델 계층을 도입하고 모든 비즈니스 및 입력 검증 로직의 99.9 %를 모델에 넣는 것입니다 골격 뷰 및 인증 로직 레이어가 될 때까지 가증을 제거합니다.
Drupal 전문가에게는 이것이 실용적인 접근법처럼 보입니까? Doctrine2가 Drupal과 잘 어울릴 수 있습니까? 아니면 Drupal 상위 레벨의 논리가 데이터와 훨씬 더 밀접하게 통합되어야합니까?
답변:
우리는 데이터가 어디에 우리가 드루팔에 외부 시스템을 연결 한 몇 사이트했던 한 외부 시스템에 보관해야합니다. 이것이 내가 대부분의 시간을 함께 일하는 시간입니다.
이 작업을 수행 할 때 일반적으로 다른 시스템의 컨텐츠를 "스텁 아웃"하는 컨텐츠 유형을 만듭니다. 컨텐츠 유형에는 다른 시스템의 고유 식별자에 대한 노드 제목 및 CCK 필드 만 포함됩니다. 이것과 함께 많은 hook_nodeapi 함수가 있습니다. 예를 들어, load후크는 원격 시스템을 호출하고 데이터를 노드에 추가합니다. 또한 외부 데이터를 검색 결과로 가져 오는 방법을 고안해야합니다. 이에 대한 몇 가지 방법이 있지만 여기에 들어가기에 너무 길다.
단점이 있지만, 이것은 잘 작동하며 주석, 태그 등과 같은 일반적인 Drupal 항목을 허용합니다.
타임 라인을 고려할 때 유일하게 현명한 일은 Drupal 7에서이를 구축하는 것입니다. Drupal 7의 가장 두드러진 특징 중 하나는 엔티티, DBNTG 및 필드입니다.
빠른 개요
이것은 일부 기능에 불과하지만 Drupal 가증을 만들고 싶지 않다면 Drupal의 작동 방식에 대해 생각하고 Drupal이 의도하지 않은 방식으로 작동하도록하는 대신 Drupal을 사용해야합니다.
Drupal은 PHP이므로 사용자 정의 모듈을 생성하고 Doctrine2를 사용하여 원하는 작업을 수행 할 수 있습니다. 그러나 내 생각에 대부분의 Drupal 사이트와 거의 공통점이없는 사이트가 생길 것입니다.
이것은 매우 광범위한 질문이므로보다 구체적인 질문이 있으면 별도의 질문으로 질문하십시오.
현재 사이트의 구조를 최대한 많이 작성하는 것이 좋습니다. 어떤 유형의 작업을 수행하고 어떤 워크 플로가 있습니까? 내용은 무엇입니까?
컨텐츠 유형은 컨텐츠를 분할하는 편리한 방법입니다. 혐오조차도 URL에 매핑되는 유형을 가지고 있었을 것입니다.
컨텐츠 유형을 결정하면 컨텐츠를 새 사이트로 마이그레이션하는 것을 볼 수 있습니다. 그런 다음 워크 플로, 일정, 사용자 등을 볼 수 있습니다.
나는 도매 이동을 선호합니다. 하나 이상의 시스템에서 컨텐츠를 관리하는 것은 기술적으로 매우 어려운 문제입니다. 그리고 유지 관리 노력을 두 배로 늘립니다.
내가 말할 한 가지는 누군가 그것을 고용 할 가치가 있다는 것입니다. 거대한 데이터 세트로 Drupal 마이그레이션이 성공적으로 수행되었습니다. 그러나 Drupal에 경험이 없다면 몇 가지 잘못된 조치를 취하고 많은 시간을 소비 할 수 있습니다. (나는 개인적으로 cyrve를 추천 할 수 있습니다 . 나는 그들과 현재 관계가 없습니다)