Gần đây, cuối cùng tôi đã bắt đầu chuyển trọng tâm của mình từ D7 sang D8 và tôi đang chuyển đổi một trang web sang D8. Trong D7, tôi đã gợi ý các đối tượng tài khoản của mình là \ stdClass, vì chúng không phải là thành viên của bất kỳ lớp nào. Tuy nhiên, trong D8, họ hiện là thành viên của lớp Người dùng.

Điều đó nói rằng, tôi đang tìm thấy trong một số mã trên mạng rằng mọi người đang đánh máy là Drupal \ Core \ Session \ AccountInterface và ở những nơi khác là Drupal \ user \ UserInterface. Làm thế nào chúng ta nên xác định cái nào sẽ sử dụng cho kiểu chữ của chúng ta, và sự khác biệt giữa hai loại đối tượng là gì?

UserInterfacemở rộng ContentEntityInterface, EntityChangedInterfacevà AccountInterface. Điều này có nghĩa là có các phương thức mà một đối tượng thực hiện UserInterfacecần phải có nhưng các đối tượng thực hiện AccountInterfacekhông cần phải có. Ví dụ, có UserInterface::hasRole(), nhưng AccountInterface::getRoles(); trong trường hợp đầu tiên, có một phương thức trợ giúp cho phép kiểm tra đối tượng có vai trò cụ thể, trong trường hợp thứ hai, bạn sẽ cần viết mã cho điều đó, lấy danh sách các vai trò với AccountInterface::getRoles().

Những gợi ý nên được sử dụng được đưa ra từ các tài liệu. Ví dụ, hook_user_logout()có được một đối tượng thực hiện \Drupal\Core\Session\AccountProxyInterface, vì nó nhận được đối tượng được trả về Drupal::currentUser(). Xem user_logout(), hàm gọi hook_user_logout().

  $user = \Drupal::currentUser();

  \Drupal::logger('user')->notice('Session closed for %name.', array('%name' => $user->getAccountName()));

  \Drupal::moduleHandler()->invokeAll('user_logout', array($user));

Đôi khi tài liệu cho một cái móc không hiển thị một gợi ý cụ thể, chẳng hạn như trong trường hợp hook_user_login(). Trong trường hợp này, có thể giúp xem gợi ý nào được sử dụng từ các triển khai của hook đó, ví dụ system_user_login(), sử dụng UserInterfacelàm gợi ý cho đối số của nó.

Khi bạn không chắc chắn về giao diện chính xác được thực hiện bởi đối tượng được truyền cho một hàm (bao gồm cả hook), hãy sử dụng giao diện chung nhất làm gợi ý. Trong trường hợp bạn mô tả, đó sẽ là AccountInterface.

Vì UserInterface mở rộng gợi ý loại cài đặt AccountInterface cho AccountInterface sẽ cho phép bạn chấp nhận cả hai loại đối tượng. Bạn có thể nghĩ về UserInterface như AccountInterface nâng cao , khai báo một vài phương thức bổ sung ( hasRole , addRole , removeRole , v.v.). Tôi sẽ sử dụng giao diện AccountInterface bất cứ nơi nào có thể trừ khi bạn cần một số phương thức bổ sung này.

Một chi tiết nữa, đối tượng của UserInterface cũng nên triển khai các phương thức từ ContentEntityInterface và EntityChangedInterface .

Kiểm tra tài liệu cho AccountInterface:

Xác định một đối tượng có id người dùng, vai trò và có thể có dữ liệu phiên. Giao diện được triển khai cả bởi phiên toàn cầu và thực thể người dùng

Nó nằm trong Sessionkhông gian tên vì một lý do - nó đại diện cho thứ gì đó có thể có dữ liệu phiên.

Các giao diện ContentEntityInterfacevà EntityChangedInterfacemở rộng bằng cách UserInterfacecho bạn biết rằng nó đại diện cho một khái niệm khác:

Các thực thể nội dung sử dụng các trường cho tất cả các thuộc tính thực thể của chúng và có thể dịch và sửa đổi được, trong khi các bản dịch và sửa đổi có thể được bật cho mỗi loại thực thể.

Xác định giao diện để theo dõi dấu thời gian thay đổi thực thể.

Dữ liệu này có thể hữu ích cho việc vô hiệu hóa bộ đệm chính xác hơn (đặc biệt là ở phía máy khách) và khóa chỉnh sửa đồng thời.

A UserInterfaceđại diện cho một tài khoản người dùng Drupal đầy đủ có thể có bản sửa đổi, trường, bản dịch, v.v.

Tôi không thể cho bạn biết cái nào phù hợp hơn cho trường hợp sử dụng của bạn, nhưng tôi khuyến khích bạn nghĩ về giao diện nào phù hợp nhất với mã bạn đang viết.

Bản năng của tôi nói với tôi rằng bạn sẽ sử dụng AccountInterfacecho một cái gì đó được "đăng nhập" tối thiểu (ví dụ: người dùng đã đăng nhập, danh sách người dùng trực tuyến, ai đó đã đăng nhập qua SSO) và UserInterfacecho bất cứ điều gì hơn thế (ví dụ: hồ sơ người dùng, tác giả liên quan, từ lâu dữ liệu được tạo ra, hầu hết mọi thứ chúng tôi làm trong Drupal).