Câu trả lời:
Đó không phải là quá nhiều về những lợi ích là gì mà nhiều hơn về những gì phù hợp cho một tình huống cụ thể như bạn đã nói. Bạn có thể đại diện cho hầu hết mọi thứ với một nút và trong 99% tình huống (như tôi đã tìm thấy ít nhất) bạn sẽ không cần phải thực hiện các loại thực thể tùy chỉnh.
Tôi luôn nghĩ về taxonomy_termloại thực thể là một ví dụ tốt về lý do tại sao mọi thứ không phải là loại nút / nội dung:
Một thuật ngữ phân loại về cơ bản là để nhóm các thực thể khác nhau lại với nhau và vì thế không yêu cầu chức năng giống như một nút. Mặc dù về mặt lý thuyết bạn có thể sử dụng một loại nội dung để thực hiện chức năng này (có lẽ là trường tham chiếu nút), thuật ngữ phân loại không cần phải làm điều tương tự như một nút để nó không thực sự có ý nghĩa. Điều tương tự có thể được nói cho các loại uservà taxonomy_vocabularythực thể.
Vì vậy, một thuật ngữ phân loại được tạo ra như một thực thể riêng biệt và được lập trình để chỉ làm những gì nó cần, trong khi vẫn nhận được lợi ích của việc có thể có các trường được đính kèm, v.v.
Tôi nghĩ rằng câu trả lời đơn giản là khi một loại nút / nội dung không làm những gì bạn cần hoặc nó chỉ là một lượng quá mức cần thiết / chi phí quá cao để có rất ít lợi ích, thì bạn nên chọn viết một thực thể tùy chỉnh.
Điều này chỉ dựa trên kinh nghiệm cá nhân của tôi; Tôi rất muốn nghe những gì một người trực tiếp liên quan đến sự phát triển cốt lõi của Drupal đã nói gì về điều này.
Một quy tắc rất đơn giản mà tôi sử dụng là liệu nội dung của bạn có cần được hiển thị công khai hay không. Nếu vậy, sau đó đi cho nút, nếu không chọn một thực thể. Entityforms hiện cho phép bạn tạo một giao diện để điền vào các thực thể của bạn.
Ví dụ: trên trang web được tạo bằng D6, chúng tôi xây dựng loại nội dung quảng cáo (với trường hình ảnh của nó, ngày hiển thị bắt đầu / kết thúc ...), nhưng sau đó bạn phải làm cho nó không được xuất bản theo mặc định và cung cấp cho biên tập viên của bạn quyền chỉnh sửa / xem các nút này và hy vọng không có lượt xem / tìm kiếm nào sẽ hiển thị các nút này ở thế giới bên ngoài. Nó khá cồng kềnh và sẽ dễ dàng hơn để đối phó với các thực thể.
Một thực thể đại diện cho một trường hợp sử dụng cụ thể .
Tôi tin rằng tín dụng cho định nghĩa đơn giản này được gửi đến Fago , nhưng tôi lười tìm một tài liệu tham khảo.
Chúng tôi có thể sử dụng Content(aka Nodes) cho tất cả các trường hợp sử dụng nếu chúng tôi muốn, nhưng thường thì điều đó không có ý nghĩa.
Content có một tác giả và cài đặt cho cả bình luận và vị trí menu.
Users, đại diện cho một trường hợp sử dụng đủ khác biệt Contentbởi vì trên usercả hai điều trên đều không có ý nghĩa gì, trong khi mặt khác, userphải có một e-mail và mật khẩu.
Taxonomy terms nổi bật bởi vì chúng có chức năng tích hợp được sắp xếp theo thứ bậc, thậm chí là hình tròn.
Nếu trường hợp sử dụng của bạn đủ tương tự với một thực thể hiện có, hãy sử dụng thực thể đó. Nếu thực thể của bạn bị chi phối bởi các quy tắc khác biệt đáng kể so với bất kỳ quy tắc hiện có nào, hãy tạo một quy tắc mới.
Ngoài ra còn có Giới thiệu về Thực thể , nhưng thật không may, nó không thực sự trả lời câu hỏi của bạn.
Tôi nghĩ đó là tất cả về bối cảnh, một nút được sử dụng chủ yếu cho nội dung vì vậy đó sẽ là blog, bài viết, faq, v.v. Trong khi người dùng cho các hồ sơ như nhân viên, khách hàng, v.v.
Mặc dù bạn có thể sử dụng một nút cho một cái gì đó như một vé hỗ trợ, nó có thể không phải là mẫu tốt nhất và mặc định ... Hy vọng điều đó sẽ giúp.
Các thực thể có thể được tạo ra với ít chi phí hơn các nút vì chúng không cần phải có tất cả các chức năng nặng mà các thực thể có.
Điều đó cũng có nghĩa là việc lưu trữ có thể đơn giản hơn - bạn có thể xây dựng chúng để lấy tất cả thông tin trong một truy vấn đơn giản mà không cần THAM GIA nếu bạn muốn. Tất cả các lĩnh vực độc đáo chỉ trong một bảng gọn gàng.
Đây có thể là một lợi ích rất lớn nếu bạn có nhiều hàm cần thực hiện truy vấn trên các thực thể và bạn đang cập nhật đồng thời nhiều thực thể với các truy vấn CẬP NHẬT vào cơ sở dữ liệu. Nếu bạn có thể đảm bảo dữ liệu tương đối khép kín trong một bảng duy nhất, bạn sẽ có ít lo lắng hơn và khả năng tham nhũng dữ liệu.
Một loại nội dung được thiết kế để là nội dung trang web. Đó là, mỗi loại nội dung được thiết kế để xuất bản và xuất hiện trên trang web. Ví dụ, một bài viết (ngoài hộp) được thiết kế để xuất hiện trên trang đầu tiên.
Bây giờ, giả sử bạn muốn tạo một cái gì đó giống như một mẫu đơn xin việc hoặc căn hộ. Rõ ràng, bạn sẽ không muốn xuất bản đơn xin việc của ai đó trên trang web của mình. Ngoài ra, nếu bạn muốn xây dựng một danh sách các liên hệ khách hàng / khách hàng tiềm năng thì sao? Bạn có muốn có cơ hội rằng thông tin này có thể được công bố do nhầm lẫn trên trang web của bạn? Cá nhân, tôi sẽ không.
Do đó, mô-đun mẫu thực thể được thảo luận ở trên. Nó cho phép bạn tạo một loại thực thể không được thiết kế để trở thành nội dung. Tuy nhiên, các loại thực thể này có sẵn cho bất kỳ mô-đun nào hỗ trợ các thực thể như quy tắc, chế độ xem và nhóm hữu cơ để chỉ một số loại.
Và sau đó bạn vào Drupal Commerce nơi các sản phẩm là các loại thực thể. Về cơ bản các thực thể cho phép các nhà phát triển mở rộng Drupal theo cách mà các nhà thiết kế Drupal ban đầu không bao giờ lường trước.
Điều này là chủ đề để thảo luận và cuối cùng, bạn phải đưa ra quyết định của mình như một nhà phát triển.
Tôi chọn các thực thể trên các nút bất cứ khi nào dữ liệu không được công khai với url riêng của chúng. Các nút đang mặc định nhận được một bí danh url, trạng thái được xuất bản, tiêu đề, thẻ meta, ... trong khi các thực thể chỉ nhận được một bản ghi trong cơ sở dữ liệu.
"Tôi muốn có thể thêm càng nhiều biểu ngữ với văn bản càng tốt và sau đó trong một blogpost chọn giữa một trong số chúng"
Thực thể vs Nội dung
Thực thể có Gói thực thể có Trường
Nội dung là một loại thực thể. Vì thế,
Nội dung có Gói nội dung (Bài viết, Trang) có Trường (nội dung, hình ảnh bài viết)
Nếu bạn là lập trình viên, bạn chắc chắn chọn con đường tạo Thực thể của riêng mình nhưng đối với những người làm việc ở đây thì đó có thể không phải là con đường tốt nhất để đi cùng. Một lần nữa, đối với người xây dựng trang web, có UI để tạo Thực thể http://drupal.org/project/eck