Tiêm phụ thuộc vào mô hình Magento 2 CRUD / Tóm tắt


12

Có thể tiêm một phụ thuộc vào mô hình Magento 2 CRUD không?

Đó là - Magento 2 có một lớp mô hình trừu tượng cơ bản : Magento\Framework\Model\AbstractModel. Nếu bạn muốn tạo một đối tượng đơn giản Tạo, Đọc, Cập nhật, Xóa mô hình, bạn mở rộng lớp này bằng lớp của riêng bạn.

class Foo extends Magento\Framework\Model\AbstractModel
{
}

Có thể có các phụ thuộc được tiêm trong __constructphương thức mô hình của bạn không? Khi tôi cố gắng, cuối cùng tôi nhận được lỗi sau.

Lỗi nghiêm trọng: Không thể khởi tạo lớp trừu tượng Magento \ Framework \ Model \ ResourceModel \ AbstractResource

Thủ phạm dường như AbstractModel__constructphương pháp của.

public function __construct(
    \Magento\Framework\Model\Context $context,
    \Magento\Framework\Registry $registry,
    \Magento\Framework\Model\ResourceModel\AbstractResource $resource = null,
    \Magento\Framework\Data\Collection\AbstractDb $resourceCollection = null,
    array $data = []
) {

Có hai gợi ý loại trong hàm tạo này ( Magento\Framework\Model\ResourceModel\AbstractResource, Magento\Framework\Data\Collection\AbstractDb) không phải là giao diện trình quản lý đối tượng Magento. Chúng là những lớp trừu tượng. Khi tôi mở rộng lớp này và cố gắng thêm phụ thuộc được tiêm của mình

class Foo extends Magento\Framework\Model\AbstractModel
{
    public function __construct(
        \Magento\Framework\Model\Context $context,
        \Magento\Framework\Registry $registry,
        \Magento\Framework\Model\ResourceModel\AbstractResource $resource = null,
        \Magento\Framework\Data\Collection\AbstractDb $resourceCollection = null,
        array $data = [],
        \Package\Module\Model\Mine $mine,

    ) {
        //...
        parent::__construct($context, $registry, $resource, $resourceCollection, $data);

    }
}

Magento bảo lãnh khi người quản lý đối tượng cố gắng khởi tạo các lớp trừu tượng.

Tôi có thể "sửa" điều này bằng cách di chuyển phụ thuộc đối tượng của mình vào trước các lớp trừu tượng

    public function __construct(
        \Magento\Framework\Model\Context $context,
        \Magento\Framework\Registry $registry,

        \Package\Module\Model\Mine $mine,

        \Magento\Framework\Model\ResourceModel\AbstractResource $resource = null,
        \Magento\Framework\Data\Collection\AbstractDb $resourceCollection = null,
        array $data = [],
    ) {  

Tuy nhiên, điều này đã thay đổi thứ tự đối số. Trong một lớp được quản lý hoàn toàn đối tượng, điều này sẽ không thành vấn đề. Tuy nhiên, thực tế là các gợi ý loại lớp trừu tượng này tồn tại ngụ ý có những phần của hệ thống Magento sẽ thủ công (tức là không thông qua trình quản lý đối tượng hoặc DI) khởi tạo các đối tượng CRUD và truyền vào các đối tượng phù hợp với gợi ý loại theo thứ tự cụ thể đó .

Cái này có an toàn không? tức là các lớp trừu tượng này trong hàm tạo của mô hình trừu tượng chỉ là mã kế thừa và không được sử dụng? Hoặc các bộ phận của hệ thống vẫn sẽ sử dụng những thứ này, có nghĩa là không thể đưa các phụ thuộc vào mô hình CRUD?

Câu trả lời:


9

Trước hết các constructor là api riêng của lớp. Hàm xây dựng có ý nghĩa đặc biệt và không yêu cầu phải có cùng danh sách / thứ tự các đối số như trong lớp cha.

Có thể tiêm một phụ thuộc vào mô hình Magento 2 CRUD không?

Phải, tất nhiên.

Cái này có an toàn không?

Có, nhưng Trình quản lý đối tượng Magento cho rằng tất cả các tham số tùy chọn được đặt ở cuối danh sách và các tham số bắt buộc sau khi tùy chọn sẽ không được giải quyết.

Các đối số $ resource, $ resourceCollection là di sản nhưng vẫn được sử dụng rộng rãi trong các lớp Model. Hầu hết các mô hình sử dụng mã như thế này để khởi tạo lớp tài nguyên và lớp thu thập.

protected function _construct() { 
    $this->_init('Magento\AdminNotification\Model\Resource Model\Inbox'); 
}

Đây là lý do tại sao các tham số này là tùy chọn. Nhưng, ví dụ, trong thử nghiệm đơn vị, chúng tôi vượt qua giả lập tài nguyên hoặc bộ sưu tập trong hàm tạo để cho phép thực hiện thay thế.


@Kanday Bộ phận kỹ thuật / kiến ​​trúc của Magento có bao giờ tuyên bố công khai rằng thứ tự xây dựng cho các lớp cốt lõi là không liên quan? Hay đó chỉ là hy vọng của hầu hết những người làm việc trên nó?
Alan Storm

Tôi sẽ không gọi nó là "không liên quan". Chỉ cần OM sẽ chuyển các đối số cần thiết cho hàm tạo của bạn và nó không phụ thuộc vào thứ tự trong lớp cha. Hơn nữa, IN sử dụng tên của các tham số, vì vậy bây giờ tốt hơn là không thay đổi chúng (khác với ngôn ngữ php, nơi bạn có thể thay đổi tên của tham số theo ý muốn)
KAndy

Tôi không chắc tôi hiểu những gì bạn nói. Bạn có nói rằng, tại một thời điểm nào đó trong tương lai, mã hệ thống Magento cốt lõi có thể bắt đầu coi thứ tự tham số / tham số là quan trọng không?
Alan Storm

Tôi tin rằng không
KAndy

cảm ơn lần nữa FWIW, và đối với các nhân viên của Google, điều này có vẻ như là một điều an toàn để làm. Từ những gì tôi có thể nói là không có mã hệ thống Magento tự động khởi tạo một cách mù quáng một mô hình giả định thứ tự tham số hàm tạo.
Alan Storm

6

Điều này dường như là an toàn. Ít nhất, magento đang làm điều này ở một số nơi. Xem các phương thức __construct trong danh sách các lớp sau (không độc quyền) để biết ví dụ

  • \ Magento \ Theme \ Model \ Theme \ File
  • \ Magento \ Theme \ Model \ Design
  • \ Magento \ Bán hàng \ Mẫu \ Đặt hàng \ Creditmemo

Thật không may, tôi không thể trả lời phần khác của câu hỏi của bạn.


4
  1. Làm thế nào để bạn sử dụng mô hình của bạn?
  2. Trong trường hợp của bạn $minelà một tham số bắt buộc , trong khi $resource, $resourceCollection$datatùy chọn . Các tham số tùy chọn phải luôn luôn đi cuối cùng, nếu không thì không thể làm việc với chúng như với tùy chọn. Vì vậy, có vẻ ổn với tôi rằng bạn nên chỉ định $minetrước bất kỳ tham số tùy chọn nào.

Ngoại trừ các tham số Trừu tượng đó không phụ thuộc vào các tham số được chèn và nếu mã hệ thống lõi Magento mong muốn chúng ở đó di chuyển $mineđến phía trước hàng đợi sẽ tạo ra lỗi. Nếu mã hệ thống lõi Magento không sử dụng chúng thì tại sao chúng lại ở đó? Đó là câu hỏi tôi đang cố gắng đi đến tận cùng. Chỉ vì tôi có thể sử dụng mô hình của mình với tham số được di chuyển không làm cho nó an toàn.
Alan Storm

Một số mô hình vẫn có thể sử dụng các tham số tùy chọn này để vượt qua mô hình tài nguyên tùy chỉnh. Ví dụ: github.com/magento/magento2/blob/develop/app/code/Magento/
gợi

Magento sử dụng sự phản chiếu để xác định xem tham số là tùy chọn hay không. Và PHP xem xét tất cả các tham số đứng trước tham số bắt buộc theo yêu cầu . Vì vậy, nếu bạn di chuyển $minetrước các tham số tùy chọn, chúng sẽ trở thành tùy chọn thực sự và Magento chỉ chuyển các giá trị mặc định ( null, array()). Nếu bạn đặt một tham số bắt buộc sau các tham số tùy chọn, PHP sẽ xem xét các tham số tùy chọn là tham số bắt buộc và Magento đã cố gắng khởi tạo chúng (nhưng không có tùy chọn nào cho chúng).
BuskaMuza

Mặc dù tôi đồng ý rằng nó có vẻ khó hiểu và có lẽ chúng ta chỉ có thể thiết lập một ưu tiên cho các lớp trừu tượng thay vì xử lý nó trong lớp mô hình. Vì vậy, một đối tượng thực sự luôn luôn được tiêm.
BuskaMuza
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.