Magento 2'deki koleksiyon geçmişi var mı?


25

Şu anda Magento 2’de (2.1.2) bulunan birçok kodun Magento 1’den çok ya da az miktarda taşındığını ve gelecekte çok sayıda kodun yerini alacağını biliyorum. Bu açıdan, Magento 2'deki koleksiyonların geleceğini merak ediyorum.

Açıklamama izin ver:

Magento 1:

Magento 1'de şöyle bir koleksiyon almaya alışkınız:

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

Daha sonra koleksiyona filtreler ve diğer işlemleri uygulayabiliriz:

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

Ve son fakat en az değil, koleksiyonumuz modelleri iade edecektir:

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

Magento 2:

Magento, daha katı bir çalışma şekli uygulayarak birçok yeni soyutlama katmanı ekler. Bu, bir varlık listesi istediğimizde, onu depodan istediğimiz anlamına gelir:

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

Biz filtreleri uygulamak istiyorsak bir arada kullanın SearchCriteriaBuilder, FilterGroupBuilder, FilterBuilderve SortOrderBuilder:

$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()
];

Ve sonuçlarımızı yinelemek istiyorsak, gerçek (kalıtsal) modeller yerine Veri Modelleri alırız:

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

Bu tür bir soyutlama, SOLID ilkesini izler ve 'mirasa karşı kompozisyon' ilkesini benimser . Koleksiyonda aksi takdirde yapılacak olan herhangi bir 'egzotik' işlem (örnekler için birleştirme gibi) depoda dahili olarak yapılır, bu da modülün dışında kullanılmasını kolaylaştırır.

Soru:

Bunların hepsi beni meraklandırıyor: Tüm veri havuzu / veri modeli yaklaşımı ile Magento 2'nin geleceği için koleksiyonlara yer var mı? Koleksiyonlar sadece modülün kendisi tarafından dahili olarak mı kullanılmalıdır, bunun dışında değil mi? Yoksa İşletme Yöneticisi lehine itiraz edilecek mi?

Şu anda, Veri Modellerini benimsemek istiyorsanız, \Magento\Framework\Model\AbstractModelyalnızca koleksiyonun çalışmasını sağlamak için kalıtsal bir model oluşturmanız Magento\Framework\Data\Collection::setItemObjectClassgerekir (çünkü modelin uzamasını gerektirir Magento\Framework\DataObject). Ve depolarınızı filtrelemek için bir koleksiyona ihtiyacınız var. Fakat daha sonra, depoda (normal) Modelinizi bir Veri Modeline dönüştürmeniz gerekir.

Yoksa bunun getList()bir örneğini döndüren Sipariş Deposu gibi uygulamak zorunda mıyız Magento\Sales\Api\Data\OrderSearchResultInterface, ancak su altında arama sonuçları bu arayüzü uygulayan normal bir koleksiyondan başka bir şey değildir. Eğlenceli gerçek: Arama sonuçları, bir Veri Modelleri dizisi ( Magento\Sales\Api\Data\OrderInterface[]) döndüreceğini belirtir , ancak kodu analiz ederseniz, hangilerinin veri modelleri değil, sıra modelleri (ayarlandığı gibi ) döndüreceğini getItems()çalıştırır . Miras üzerine kompozisyon için çok fazla.Magento\Framework\Data\Collection::getItems()Magento\Sales\Model\ResourceModel\Order\Collection::_construct()

Magento 2'de doğru yolun ne olduğuna dair birçok soru var. Yine, aynı şeyi yapmanın 100 yolu var, ama 'Magento Yolu' nedir? Yoksa burada tamamen yanlış yolda mıyım?


2
Burada gerçek soruları sormak +1. Buradaki temel dev cevabı gerçekten çok isterdim
Marius

Planın Koleksiyonlar'in kaldırılması olduğuna inanıyorum. Ancak, fark ettiğiniz gibi, bu neredeyse başarılmaya bile yakın değildir ve çeşitli durumlarda yeniden yapılandırılmış gibi görünen birçok alan vardır (Magento \ Sales \ Api \ Data \ OrderSearchResultInterface gibi sabit bir api'ye sahip olmak, Magento’nun yerini almasına izin verir. daha sonra kaputun altında daha kolay olur). GetList'in çeşitli uygulamalarının şu anda koleksiyonlarla yapabileceklerimiz kadar yetenekli olmamasına yardımcı olmuyor. Belirtilen geri dönüşle ilgili not ettiğiniz tutarsızlık, github ile ilgili bir sorun için faydalı olabilir.
Fooman'daki Kristof,

Yanıtlar:


16

Koleksiyonlar artık geçerli değil. Bazı modüller zaten Servis Sözleşmesi API'lerini gösterirken, diğerleri hala yalnızca Model / Koleksiyon API'lerini gösterir.

Plan şudur:

  1. Mevcut durumu daha iyi @api kapsama alanıyla yansıtın: @api bulunan bazı modüllerde soyut koleksiyonları ve belirli koleksiyonları açıklama
  2. Mirasa dayalı API'lere güvenmeden Servis Sözleşmelerinin kolay oluşturulmasını sağlamak için kalıcılık çerçevesini iyileştirme: Koleksiyonlar, Modeller, Kaynak modelleri
  3. Hizmet Sözleşmelerinin koleksiyona dayalı uygulamalarının teşvik edilmemesi için Özet Koleksiyonun kullanımdan kaldırılması
  4. Service Contract API'ları olan modüllerin daha yeni sürümlerini aşamalı olarak bırakın

Yani koleksiyonlar bir noktada kullanımdan kaldırılacak, ancak şimdi onlar Magento 2 API'lerinden biri.

Hizmet Sözleşmelerinin uygulanmasına gelince, - Modeller ve Koleksiyonlar Magento'da uygulamanın tek uygun yoludur <= 2.1. Servis Sözleşmeleri sadece Arayüzlerdir. Bunların uygulanması genel API’nin bir parçası değildir ve daha sonra değiştirilebilir.


1
Cevabınız için teşekkürler. Peki, yeni modüller yaratan geliştiriciler için tavsiyeniz nedir? Mevcut stratejim (su altında) hala koleksiyonları kullanan hizmet sözleşmeleri oluşturmak çünkü a) filtrelemeyi kolaylaştırıyor ve b) işletme yöneticisi hala çok deneysel / belgesiz. Bir noktada, içsel işler başka herhangi bir şeyle değiştirilebilir ancak arayüz aynı kalır. Ama cevabınızı doğru anlarsam, şu an için doğru yol bu mu?
Giel Berkers

Doğru. Bunu yansıtmak için cevabımı değiştirdim.
Anton Kril,

1
Yukarıdakileri göz önüne alarak, hizmet sözleşmeleri yoluyla elde edilemeyen verileri gerektiren işlevselliği uygulamak için uygun yol ne olabilir? Örneğin, eğer modül A tüm siparişlerin ödeme yöntemine göre filtrelenmesini gerektiriyorsa.
Stjepan
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.