Magento 2: Modeller ve Veri Modelleri Arasındaki Fark

Magento 2'nin hizmet sözleşmesi mimarisinin bir parçası olarak veri modelleri getirdiğinin farkındayım. Veri modelleri genellikle bir modülün Api / Data / öğesinde tanımlanan arayüzleri uygular.

Ancak, Magento eski modelleri de korumuş görünüyor.

Modül-müşteriye bir örnek verelim.

• Api / Data / CustomerInterface.php içinde tanımlanan veri modeli arayüzü
• Yukarıdaki arayüz Model / Data / Customer.php içinde uygulanır.
• Veri modeli, beklendiği gibi müşteri değişkenleri için tüm alıcı ve ayarlayıcı işlevine sahiptir
• Yukarıdakilere ek olarak bir Model / Customer.php de vardır. Bu da alıcı ve ayarlayıcı işlevine sahiptir. Bu daha çok ResourceModel'e (Model / ResourceModel / Customer.php) bağlanan bir Magento 1 modeline benzer
• Model / ResourceModel / CustomerRepository.php'de, çeşitli işlevler Magnento 1 modelinden veri toplar, bunları veri modeline aktarır ve sonra veri modelini döndürür.

Neden eski modele ihtiyaç var? Veri modeli neden ResourceModel ile doğrudan bağlanamıyor?

Açıklamam:

Bir model ile bir veri modeli arasındaki farkı anlamak çok zordur. Birkaç kelimeyle söylemek gerekirse, bir modelin motoru ve bir veri modelinin bilgilerini temsil ettiğini söyleyebilirim .

Örneğin, müşteri kuruluşuyla, örneğin , motorun bir parçası oldukları ve bilgileri doğrudan işlemeyecekleri için yöntemin authenticateveya validatePasswordmüşteri modelinde nasıl tutulduğunu görebilirsiniz . Öte yandan, bilgi parçalarının ele alınması gibi yöntemler veri modelinde tutulur.getExtensionAttributes

Bence bu sadece daha iyi bir proje yönetimi, tıpkı modeller ve kaynak modelleri arasındaki ayrım gibi, onlara neden ihtiyacınız olduğunu da sorabilirsiniz.

Neden onlara ihtiyacınız var:

Müşteri bilgilerini (örneğin) API kullanarak göstermek istiyorsanız, kuruluşunuzun tüm özelliklerini tanımlayan alıcıları olan bir arayüze ( \Magento\Customer\Api\Data\CustomerInterface) ihtiyacınız olacak ve ifşa etmek istediğiniz bilgileri temsil etmeyen başka bir alıcı yönteminiz varsa (ör: ), bir sorunun var!getRandomConfirmationKey

Thi, benim örneğimde, veri modelinin bir parçası iken , getRandomConfirmationKeymodelin ( \Magento\Customer\Model\Customer) bir getFirstnameparçasıdır.

Hızlı bir kural şöyle olabilir:

• Metodunuz bir tablo sütununu, bir niteliği veya herhangi bir varlık bilgisini temsil ediyorsa, veri modeline girilmelidir .
• Metodunuz bilgi üzerinde bir "eylem" ise, bilgiyi işler veya webapi.xml dosyasında bildirirseniz , bir model metodu olmalıdır .

İLETİ:

Birkaç kelimeyle: bir veri modelini neredeyse bir DTO olarak düşünün.

@ Phoenix128_RiccardoT cevabına ek olarak, havuzların (yani MagentoCms\Api\BlockRepositoryveya Magento\Customer\Api\CustomerRepositoryInterface) düzenli olarak değil veri modeli sağlamanızı beklediğidir. Veri modelleri, yalnızca işletme tarafından sağlanan verileri ortaya çıkaran standart modeller üzerinde bir soyutlama katmanıdır. Bu veriler üzerindeki tüm "eylemler" başka bir yere taşınır.

Biraz varlık Symfony2 ve Symfony3 varlık varlık fikrine benziyor burada varlık sadece veri içerir ve varlık yöneticisi varlık veri yer alıyor. Magento2'de bu rolün depolara verildiğine inanıyorum.

Eski modeller hala bizimle çünkü çünkü magento2 geliştirildi. Açıkçası boş index.php'den başlamadılar, ancak M1'den bazı kodları yeniden kullandılar. Eğer standart model yöntemlerine bir göz atın zaman ( load(), save()ve delete()) bütün olarak işaretlenir deprecated. Bunun nedeni, o işin depolara taşınmasıdır (bazı durumlarda tüm deponun şimdi bu normal model save()yöntemini çağırdığı kabul edilir, ancak yol benim için net görünüyor).

Modeller depolama bağımsız iş mantığını kapsüllemektedir, Magento 2 veri modellerinde veritabanı motorları veya örnekleri hakkında bilmiyorlar, Veri Aktarım Nesneleri (DTO'lar), Magento CRUD modelleri (model için DTO (veri modeli) özel arayüzlerinin uygulanmasıdır. ) Magento WebAPI aracılığıyla hangi sınıf yöntemlerinin kullanılabileceğini belirler.

Model/Data/Customer.phpAPI için hangi yöntemlerin kullanılabilir olduğunu belirler, oysa Model/Customer.phpAPI olmayan işlemler için kullanılabilen eski Magento 1 tipi özel alıcılar ve ayarlayıcılar uygulaması vardır.

Model/ResourceModel/CustomerRepository.php Magento 2 - Hizmet Sözleşmeleri'nde tanıtılan yeni bir özelliğin bir parçasıdır, DTO (Veri Modelleri) kombinasyonu ile çalışır.

Magento ORM'in Modellerden, Kaynak Modellerden ve Koleksiyonlardan oluştuğunu ve Veritabanına bağlı olduğunu bildiğimiz için, Hizmet Sözleşmesinin amacı, depolama mantığını gizlemektir, böylece Depoya (Hizmet Sözleşmesi) bağlı bir istemci hedef depolamayı önemsemez motor.