Bực mình vì hàng tấn lớp học cho DI trong các nhà xây dựng của Magento 2 - có cách nào tốt hơn không?

Tại thời điểm này, tôi cảm thấy khó chịu khi viết các hàm tạo tương tự như sau trong các mô-đun của mình.

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

    /* ... */

    \Foo\Bar\Model\Baz $baz,

    /* ... */

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

    /* ... */

    $this->baz = $baz;

    /* ... */

    /* some awesome stuff */
}

Trong nhiều trường hợp, tôi cần các thể hiện của cùng một lớp trên mô-đun của mình.

Vì vậy, tôi đã tự đặt câu hỏi, liệu đó có phải là một cách chấp nhận được để sử dụng một hoặc hai lớp trợ giúp trung tâm, cung cấp các lớp cần thiết, thay vì định nghĩa chúng trong mỗi hàm tạo.

Điều này có nghĩa là một mô hình như thế này:

Lớp người trợ giúp

namespace Foo\Bar\Helper

class Main
{
    protected $baz;



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

        /* ... */

        \Foo\Bar\Model\Baz $baz,

        /* ... */
    ) {
        $this->registry = $registry;

        /* ... */

        $this->baz = $baz;

        /* ... */

        /* some awesome stuff */
    }



    public function getBazInstance()
    {
        return $this->baz;
    }
}

Các constructor ngắn hơn

public function __construct(

    \Foo\Bar\Helper\Main $mainHelper,

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

    /* some awesome stuff */
}

Tại thời điểm này tôi không chắc chắn liệu tôi sẽ phải đối phó với những bất lợi lớn trong tương lai do cấu trúc này gây ra hay không. Đây có phải là một cách chấp nhận được để giảm số lượng định nghĩa DI?

Kiểm tra \Magento\Framework\Model\Context, tham khảo trong ví dụ của bạn. Những gì bạn mô tả là chính xác những gì nó làm. Magento sử dụng các Contextđối tượng tương tự trong suốt lõi để rút ngắn danh sách DI.

Điều duy nhất cần ghi nhớ là điều này không nên được sử dụng để che giấu các quyết định kiến ​​trúc xấu . Bạn nên xem xét liệu mỗi lớp bạn cần 'trên tất cả các mô-đun của bạn có thực sự cần thiết hay không, và nếu vậy, liệu có cách nào khác để tổ chức mã của bạn sẽ hoàn thành cùng một mục tiêu hay không. Thật dễ dàng để giới thiệu các vấn đề hiệu suất không chủ ý.

Tôi khá chắc chắn rằng bạn không phải là người duy nhất trong trường hợp này và theo một cách nào đó tôi hoàn toàn hiểu lý do tại sao bạn nghĩ về việc này.

Đối với tôi, vấn đề chính tôi thấy với cách tiếp cận như vậy là bạn mất một trong những lợi ích chính của Dependency Injection, đó là phải biết ngay lớp của bạn phụ thuộc vào điều gì khi kiểm tra hàm tạo.

Một lợi ích quan trọng khác của Dependency Injection là nó giúp mã dễ kiểm tra hơn trong một khung tự động. Trong trường hợp của bạn đó chắc chắn là một nhược điểm.

Đó là hai lý do đưa ra nhưng có thể có nhiều hơn.

EDIT: Tôi sẽ thêm một trích dẫn từ Alan Kent (một phần của Magento) mà bạn có thể tìm thấy trong các bình luận của câu hỏi này :

Tôi thường không khuyến khích việc ném các phương thức vào một lớp trợ giúp không liên quan. Tốt hơn là có các lớp riêng biệt đại diện cho mục đích thực sự. Hoặc sử dụng các phương thức tĩnh trong trường hợp không cần đến hàm tạo (mã gọi có trách nhiệm xử lý các cấu trúc dữ liệu cần thiết).