Tôi đã thấy một số chiến lược để tích hợp các cấu trúc dữ liệu từ xa trong Drupal. Các chiến lược dường như đã phát triển khi các mô-đun nhất định đã ổn định và các trường hợp sử dụng đã được thử.

Hãy tưởng tượng chúng ta có một cấu trúc dữ liệu "Thị trường nông dân" được thể hiện bằng một số loại dữ liệu (market, market_hours, vender, stall, sản xuất), v.v. được hiển thị thông qua API REST. ID cho dịch vụ bên ngoài sẽ cần liên quan đến Drupal, tức là khi tải "thị trường", chúng tôi muốn lấy dữ liệu từ 'market_hours' và 'stall'. Điều gì sẽ là cách tốt nhất để thể hiện nội dung chỉ đọc trong Drupal được đồng bộ hóa thường xuyên?

Tôi đang cố gắng đánh giá điều này với các tiêu chí sau:

Cấu trúc dữ liệu trong Drupal:

Nút và thực thể tùy chỉnh

Một số tình huống liên quan đến các dịch vụ web tôi đã thấy sử dụng các thực thể tùy chỉnh. Nó đơn giản hóa ops CRUD. Tuy nhiên, các mục này sẽ là "nội dung" trong đó chúng sẽ được xem công khai.

Lưu trữ (Cục bộ so với từ xa):

Tôi đã thấy một vài ví dụ trong đó các dịch vụ được tải dưới dạng các thực thể từ xa, mà mô-đun này tạo ra một thư viện cho: https://drupal.org/project/wsdata . Điều này nghe có vẻ hấp dẫn nhất, nhưng chưa thấy nhiều trường hợp sử dụng. Ngoài ra còn có ví dụ về mã tùy chỉnh: https://drupal.org/sandbox/fago/1493180

Đồng bộ hóa dữ liệu:

Nguồn cấp dữ liệu so với Di chuyển so với Hướng dẫn so với 'Máy khách dịch vụ web' so với 'Dữ liệu dịch vụ web'

Có một số tùy chọn. Nguồn cấp dữ liệu hiện hỗ trợ các thực thể. Di chuyển có vẻ sạch hơn rất nhiều so với nguồn cấp dữ liệu, đặc biệt đối với các kịch bản tùy chỉnh. Tôi cũng đã thấy mọi người sử dụng một ứng dụng khách để tìm đồng bộ hóa với các dịch vụ từ xa: http://drupalcode.org/project/ckan.git/blob/refs/heads/ckan_dgu_7.x-1.x:/ckan.drush. inc # l273 . Tôi cũng nhận thấy mô-đun WS Client https://drupal.org/project/wsclient cung cấp một tùy chọn đã được tạo cụ thể như một máy khách còn lại. Dữ liệu dịch vụ web tải trực tiếp từ một dịch vụ và lưu trữ cục bộ.

Cảm ơn cho bất kỳ suy nghĩ.

1. Cải cách câu hỏi

Ví dụ của bạn cho thấy rằng dữ liệu chỉ được đọc ở phía Drupal, chỉ đồng bộ hóa một chiều. Tôi nghĩ đây là yếu tố quan trọng nhất cần xem xét ở đây, bởi vì thực tế, bất kỳ giải pháp nào bạn thực hiện sẽ là một biến thể của lưu trữ từ xa, đồng bộ hóa và bộ nhớ đệm cục bộ - ngay cả khi bộ nhớ đệm cục bộ kết thúc là các thực thể trong cơ sở dữ liệu Drupal.

Vì vậy, câu hỏi, thay vì là "lưu trữ cục bộ và lưu trữ từ xa" sẽ là:

• Nếu bạn nên lưu trữ dữ liệu cục bộ;
• Bạn nên lưu trữ dữ liệu dưới dạng thực thể thực tế và sử dụng Nguồn cấp dữ liệu (hoặc tương tự) để đồng bộ hóa dữ liệu thường xuyên; HOẶC LÀ
• Nếu bạn sử dụng một số mô-đun được thực hiện tùy chỉnh cung cấp đồng bộ hóa và bộ đệm.

Một bài viết bạn có thể quan tâm là " Các thực thể từ xa trong Drupal 7 ".

2. Lưu trữ dữ liệu

Nói chung, lưu trữ dữ liệu là một ý tưởng tốt:

• Bạn được bảo vệ trước sự cố ngừng hoạt động của các dịch vụ khác hoặc thời gian chờ trong kết nối;

• Có dữ liệu của bạn trong cơ sở dữ liệu Drupal của bạn sẽ tăng tốc hoạt động;

• Có dữ liệu của bạn trong cơ sở dữ liệu Drupal của bạn sẽ có nghĩa là bạn có nhiều khả năng tích hợp với các mô-đun khác, chẳng hạn như Chế độ xem (mặc dù điều này không được đảm bảo).

Ưu điểm duy nhất của việc không lưu trữ dữ liệu là bạn không bao giờ nhận được dữ liệu cũ, trong một số trường hợp là tốt hơn - đôi khi không nên hiển thị dữ liệu hơn là dữ liệu cũ. Tôi không thấy đây là một lợi ích trong ví dụ bạn đã đưa ra, vì vậy tôi sẽ tập trung câu trả lời này vào một giải pháp liên quan đến bộ nhớ đệm cục bộ.

3. Thực thể cục bộ + Đồng bộ hóa

Nếu bạn chọn tùy chọn có các thực thể cục bộ và tự đồng bộ hóa chúng, thì chúng tôi sẽ quay lại câu hỏi ban đầu của bạn:

• Bạn nên sử dụng các nút hoặc các thực thể tùy chỉnh;

• Mô-đun nào là tốt nhất để đồng bộ hóa.

3.1 Nút và thực thể tùy chỉnh

• Định nghĩa chính xác của một nút là một nút khá mở. Các trang tài liệu trên các nút gợi ý rằng nút là "gửi bài" được "lưu trữ" trên trang web của bạn - không phải trong đó áp dụng cho dữ liệu của bạn;

• Là một nhà phát triển Drupal, tôi hy vọng rằng nếu một cái gì đó là một nút thì tôi sẽ có thể thao tác nó trên chính trang web đó;

• Là người dùng Drupal, tôi cũng mong muốn các nút có thể được chỉnh sửa tương tự;

• Vấn đề Drupal 8 này https://drupal.org/node/2019031 cho thấy khái niệm "chỉ đọc" là một khái niệm sẽ áp dụng ở cấp thực thể, thay vì ở cấp độ gói. Nếu điều này được thực hiện, bạn sẽ được hưởng lợi từ nó bằng cách đi xuống tuyến đường này.

Tóm lại: dữ liệu của bạn chỉ được đọc và được lưu trữ từ xa , nên sử dụng loại thực thể tùy chỉnh để thể hiện dữ liệu của bạn có ý nghĩa hơn.

3.2 Đồng bộ hóa

Đối với phần thứ hai, hai mô-đun chính cho điều này là, như bạn đề xuất, Nguồn cấp dữ liệu và Di chuyển .

Sự khác biệt giữa Nguồn cấp dữ liệu và Di chuyển là Nguồn cấp dữ liệu được xây dựng để nhập nội dung thường xuyên, trong khi Di chuyển được xây dựng để chuyển nội dung một lần từ nơi này sang nơi khác. Di chuyển không hỗ trợ cập nhật dữ liệu hiện có, tuy nhiên do cả hai mô-đun đều được hỗ trợ tốt nên sử dụng mô-đun được xây dựng cho nhiệm vụ trong tay sẽ hợp lý hơn - Nguồn cấp dữ liệu phù hợp hơn.

Bản thân tôi đã sử dụng cả hai mô-đun (Nguồn cấp dữ liệu để đồng bộ hóa, Di chuyển để di chuyển) Tôi không thấy Nguồn cấp dữ liệu lộn xộn hơn Di chuyển. Di chuyển đã yêu cầu nhiều mã tùy chỉnh hơn theo kinh nghiệm của tôi, mặc dù việc di chuyển toàn bộ trang web phức tạp hơn so với nhập các loại nội dung đơn lẻ, vì vậy thật khó để so sánh.

4. Mô-đun tùy chỉnh để lưu trữ từ xa, đồng bộ hóa + bộ nhớ đệm

Có một số mô-đun ngoài kia có thể giúp với nhiệm vụ này.

Bạn đã đề cập đến mô-đun Dữ liệu Dịch vụ Web và những người khác đã đề cập đến mô-đun Dữ liệu . Một tùy chọn khác để xem xét là mô-đun API thực thể từ xa . Lưu ý rằng người duy nhất tôi có kinh nghiệm là mô-đun Dữ liệu.

• Mô-đun Dữ liệu Dịch vụ Web chưa có bản phát hành - có thể cho biết mã chưa ổn định, API có thể thay đổi, v.v. Nó không hỗ trợ Truy vấn thực thể (theo trang dự án của nó) và trình duyệt nhanh của kho lưu trữ mã cho thấy không có bằng chứng nào về việc nó có hỗ trợ Lượt xem - vì vậy bạn sẽ không thể sử dụng Chế độ xem để hiển thị các thực thể của mình;

• Theo kinh nghiệm của tôi, mô-đun Dữ liệu được định hướng nhiều hơn, hướng tới những người không phải là nhà phát triển có dữ liệu trong một bảng và muốn đưa nó ra xem. Tôi đã tìm thấy phiên bản Drupal 6 khá khó sử dụng - mặc dù điều đó có thể đã thay đổi kể từ đó;

• Mô-đun API thực thể từ xa nghe có vẻ khá hứa hẹn - nó hỗ trợ tìm nạp và lưu trữ bộ đệm của các thực thể từ xa và có hỗ trợ Chế độ xem. Nó chỉ được phát hành alpha - vì vậy API vẫn có thể thay đổi. Thoạt nhìn có vẻ như nó cũng không hỗ trợ Truy vấn thực thể và nó chỉ hỗ trợ một loại dịch vụ từ xa nên bạn sẽ phải tự thực hiện.

Phần kết luận

Do không có mô-đun lưu trữ từ xa nào hỗ trợ Truy vấn thực thể, sử dụng thực thể + nguồn cấp dữ liệu là giải pháp sẽ cung cấp cho bạn sự tích hợp tốt nhất với trang web Drupal của bạn.

Nếu hỗ trợ Lượt xem là đủ và bạn không lo lắng về việc tích hợp tiềm năng với các mô-đun khác thông qua Truy vấn thực thể, thì sử dụng API thực thể từ xa có thể là cách tốt nhất - tuy nhiên bạn sẽ cần phải thực hiện giao diện từ xa của riêng mình.

Nếu bạn cần chế độ xem, quy tắc, mã thông báo, móc nối, tìm kiếm api và tích hợp hệ thống mạnh mẽ theo quan điểm của tôi, chúng có thể được coi là các nút nhưng chúng phải là các thực thể tùy chỉnh với lưu trữ idiosyncrasy của riêng chúng trong cơ sở dữ liệu là "id thực thể" và Mối quan hệ "id bên ngoài" và với các cuộc gọi thông tin truy xuất được gói gọn trong "thuộc tính thực thể". Cuối cùng, bất kể công cụ nào bạn chọn để đồng bộ hóa dữ liệu, tôi sẽ xử lý nó với Hàng đợi cron.

Nếu bạn chỉ cần truy xuất và hiển thị dữ liệu đúng giờ, tôi nghĩ rằng một lựa chọn tốt hơn sẽ là tạo một lớp Giao diện để lấy dữ liệu ngoài và triển khai Giao diện này với Lớp lấy thông tin từ cấu trúc "Thị trường nông dân" của bạn.

Trân trọng

Có API lưu trữ trường , cho phép lưu trữ ngược có thể cắm được ngoài các công cụ cơ sở dữ liệu mặc định.