Là bộ sưu tập lịch sử trong Magento 2?


25

Tôi biết rằng rất nhiều mã hiện có trong Magento 2 (2.1.2) được chuyển ít nhiều từ Magento 1 và rất nhiều mã sẽ được thay thế bằng một tương đương trong tương lai. Ở khía cạnh này, tôi tự hỏi tương lai của các bộ sưu tập trong Magento 2 là gì.

Hãy để tôi giải thích:

Magento 1:

Trong Magento 1, chúng ta thường có được một bộ sưu tập như thế này:

$products = Mage::getModel('catalog/product')->getCollection();

Sau đó chúng tôi có thể áp dụng các bộ lọc và các hoạt động khác cho bộ sưu tập:

$products->addAttributeToFilter('price', ['gteq' => 10]);
$products->addFieldToFilter('created_at', ['lt' => '2016-10-10']);
$products->setPageSize(10);
// ... etc ...

Và cuối cùng nhưng không kém phần quan trọng, bộ sưu tập của chúng tôi sẽ trả về các mô hình:

foreach ($products as $product) {
    echo get_class($product); // Mage_Catalog_Model_Product
}

Magento 2:

Magento bổ sung rất nhiều lớp trừu tượng mới, thực hiện một cách làm việc RẮN hơn. Điều này có nghĩa là khi chúng tôi muốn một danh sách các thực thể, chúng tôi yêu cầu nó từ một kho lưu trữ:

$productResults = $this->productRepository->getList($searchCriteria);

Nếu chúng tôi muốn áp dụng các bộ lọc, chúng tôi sử dụng kết hợp các SearchCriteriaBuilder, các FilterGroupBuilder, FilterBuilderSortOrderBuilder:

$this->searchCriteriaBuilder->addSortOrder(
    $this->sortOrderBuilder
        ->setField('created_at')
        ->setAscendingDirection()
        ->create()
);
$priceFilter = $this->filterBuilder
    ->setField('price')
    ->setValue(10)
    ->setConditionType('gteq')
    ->create();
$createdAtFilter = $this->filterBuilder
    ->setField('created_at')
    ->setValue('2016-10-10')
    ->setConditionType('lt')
    ->create();
$filterGroups = [
    $this->filterGroupBuilder->addFilter($priceFilter)->create(),
    $this->filterGroupBuilder->addFilter($createdAtFilter)->create()
];

Và nếu chúng tôi muốn lặp lại kết quả của mình, chúng tôi sẽ nhận được Mô hình dữ liệu, chứ không phải mô hình thực tế (được kế thừa):

foreach ($productResults->getItems() as $product) {
    echo get_class($product); // \Magento\Catalog\Model\Data\Product
}

Kiểu trừu tượng này tuân theo nguyên tắc RẮN và bao trùm 'thành phần trên thừa kế' . Bất kỳ hoạt động 'kỳ lạ' nào khác sẽ được thực hiện trên bộ sưu tập (như tham gia ví dụ) đều được thực hiện trong kho lưu trữ, điều này cũng giúp sử dụng bên ngoài mô-đun dễ dàng hơn.

Câu hỏi:

Tất cả những điều này khiến tôi tự hỏi: với toàn bộ cách tiếp cận mô hình dữ liệu / kho lưu trữ, liệu có bất kỳ phòng nào trong tương lai của Magento 2 cho các bộ sưu tập không? Có phải các bộ sưu tập chỉ được sử dụng nội bộ bởi chính mô-đun chứ không phải bên ngoài mô-đun? Hay là sẽ bị từ chối ủng hộ Trình quản lý thực thể?

Hiện tại, nếu bạn muốn nắm lấy Mô hình Dữ liệu, bạn vẫn phải tạo một mô hình được kế thừa (được kế thừa từ \Magento\Framework\Model\AbstractModel) chỉ để làm cho bộ sưu tập hoạt động (vì Magento\Framework\Data\Collection::setItemObjectClassyêu cầu mô hình phải mở rộng từ đó Magento\Framework\DataObject). Và bạn cần phải thu thập để có thể lọc trong kho lưu trữ của bạn. Nhưng một lần nữa, trong kho lưu trữ, bạn phải 'chuyển đổi' Mô hình (thông thường) của mình thành Mô hình Dữ liệu.

Hoặc chúng ta phải triển khai nó như Kho lưu trữ đơn hàng, nơi getList()trả về một thể hiện của Magento\Sales\Api\Data\OrderSearchResultInterface, nhưng dưới nước, kết quả tìm kiếm không gì khác hơn là một bộ sưu tập thông thường thực hiện giao diện này. Thực tế thú vị: kết quả tìm kiếm cho biết nó sẽ trả về một mảng Mô hình dữ liệu ( Magento\Sales\Api\Data\OrderInterface[]), nhưng nếu bạn phân tích mã, getItems()sẽ thực hiện Magento\Framework\Data\Collection::getItems()trả lại không phải là mô hình dữ liệu, mà là mô hình thứ tự (như được đặt bởi Magento\Sales\Model\ResourceModel\Order\Collection::_construct()). Quá nhiều cho 'thành phần trên thừa kế'.

Rất nhiều câu hỏi về cách thức phù hợp trong Magento 2. Một lần nữa, có 100 cách để làm điều tương tự, nhưng 'The Magento Way' là gì? Hay tôi hoàn toàn đi sai đường ở đây?


2
Đặt câu hỏi thực sự ở đây +1. Tôi thực sự thích một câu trả lời dev cốt lõi ở đây
Marius

Tôi tin rằng kế hoạch dành cho Bộ sưu tập sẽ được loại bỏ. Tuy nhiên, như bạn nhận thấy điều này gần như không hoàn thành và có rất nhiều lĩnh vực dường như đang được tái cấu trúc (có api ổn định như Magento \ Sales \ Api \ Data \ OrderSearchResultInterface, cho phép Magento thay thế những gì xảy ra dưới mui xe dễ dàng hơn sau này). Điều đó không giúp ích gì cho việc triển khai getList khác nhau chưa có khả năng như những gì chúng ta hiện có thể làm với các bộ sưu tập. Sự không nhất quán mà bạn lưu ý xung quanh lợi nhuận đã nêu có thể xứng đáng cho một vấn đề trên github.
Kristof tại Fooman

Câu trả lời:


16

Bộ sưu tập không được phản đối bây giờ. Mặc dù một số mô-đun đã hiển thị API Hợp đồng dịch vụ, một số mô-đun khác vẫn chỉ hiển thị API Mô hình / Bộ sưu tập.

Kế hoạch là:

  1. Phản ánh trạng thái hiện tại với phạm vi bảo hiểm @api tốt hơn: chú thích các bộ sưu tập trừu tượng và các bộ sưu tập cụ thể trong một số mô-đun với @api
  2. Cải thiện khung kiên trì để cho phép dễ dàng tạo Hợp đồng dịch vụ mà không cần phụ thuộc vào API dựa trên kế thừa: Bộ sưu tập, Mô hình, Mô hình tài nguyên
  3. Không dùng Bộ sưu tập Tóm tắt để không thúc đẩy triển khai Hợp đồng dịch vụ dựa trên bộ sưu tập
  4. Dần dần phát hành các phiên bản mới hơn của các mô-đun với API hợp đồng dịch vụ

Vì vậy, các bộ sưu tập sẽ bị phản đối tại một số điểm, nhưng bây giờ chúng là một trong các API Magento 2.

Đối với việc triển khai Hợp đồng dịch vụ, - Mô hình và Bộ sưu tập là cách thuận tiện duy nhất để triển khai chúng trong Magento <= 2.1. Hợp đồng dịch vụ chỉ là Giao diện. Việc triển khai của họ không phải là một phần của API công khai và có thể được thay đổi sau đó.


1
Cảm ơn câu trả lời của bạn. Vậy lời khuyên của bạn cho các nhà phát triển tạo ra các mô-đun mới là gì? Chiến lược hiện tại của tôi là tạo ra các hợp đồng dịch vụ mà (dưới nước) vẫn sử dụng các bộ sưu tập vì a) nó giúp lọc dễ dàng và b) trình quản lý thực thể vẫn còn quá thử nghiệm / không có giấy tờ. Tại một số điểm, các hoạt động bên trong có thể được thay thế bởi bất cứ điều gì khác nhưng giao diện vẫn giữ nguyên. Nhưng nếu tôi hiểu chính xác câu trả lời của bạn thì đó là cách thích hợp phải không?
Giel Berkers

Chính xác. Tôi chỉnh sửa câu trả lời của tôi để phản ánh điều này.
Anton Kril

1
Xem xét ở trên, điều gì sẽ là cách thích hợp để thực hiện chức năng yêu cầu dữ liệu không thể tìm nạp thông qua hợp đồng dịch vụ? Ví dụ: nếu mô-đun A yêu cầu tất cả các đơn đặt hàng được lọc theo phương thức thanh toán.
Stjepan
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.