Magento 2 Helper เช่น

เมื่อฉันคิดว่าฉันเอาหัวของฉันพันรอบระบบ DI จาก Magento 2 มีบางอย่างเกิดขึ้นและไม่ห่อหุ้ม
ฉันเห็นรหัสหลักในวิธีต่างๆในการเข้าถึงตัวช่วย
ตัวอย่างเช่นในMagento\Catalog\Controller\Category::_initCategoryสิ่งนี้:

if (!$this->_objectManager->get('Magento\Catalog\Helper\Category')->canShow($category)) {
    return false;
}

แต่ในMagento\Catalog\Block\Category\Viewตัวช่วยถูกฉีดเข้าไปในตัวสร้างเขา

public function __construct(
    \Magento\Framework\View\Element\Template\Context $context,
    \Magento\Catalog\Model\Layer\Category $catalogLayer,
    \Magento\Framework\Registry $registry,
    \Magento\Catalog\Helper\Category $categoryHelper,
    array $data = array()
) {
    $this->_categoryHelper = $categoryHelper;
    $this->_catalogLayer = $catalogLayer;
    $this->_coreRegistry = $registry;
    parent::__construct($context, $data);
}

นี้ทำให้ฉันคิดว่าผู้ช่วยเหลือควรจะแตกต่างกันในการเข้าถึงตัวควบคุมและบล็อก (และรุ่น) Magento\Catalog\Controller\Adminhtml\Product\Action\Attributeแต่แล้วผมพบว่าตัวควบคุมที่เป็นผู้ช่วยที่ถูกฉีดในตัวสร้างที่

โปรดล้างหมอกให้ฉันด้วย
ฉันควรใช้ DI และควรใช้เมื่อobjectManagerใด และทำไม?
ฉันได้อ่านคำถามนี้: อินสแตนซ์ช่วยในวีโอไอพี 2 นี่เป็นเพียงคำถามติดตามที่

ฉันชอบ DI มากที่สุดเท่าที่เป็นไปได้เนื่องจากการใช้ตัวจัดการวัตถุนั้นเป็นการฝ่าฝืนกฎหมายว่าด้วยความผิดทางอาญา เมื่อใช้ตัวจัดการวัตถุการพึ่งพาเหล่านี้จะถูกซ่อนอยู่ในตรรกะวิธี

ผมไม่ทราบว่ามากเกี่ยวกับการดำเนินงานวีโอไอพี แต่ดูเหมือนว่าObjectManagerเป็นสบริการ

โดยทั่วไปใช้บริการสอ้างอิงในการเข้าถึงวัตถุที่ไม่ดีงาม, เช็คเอาท์ออกจากบทความนี้

การกำหนดการพึ่งพาของคุณอย่างชัดเจนผ่านคอนสตรัคเตอร์เป็นวิธีการที่ดีกว่ามาก มันช่วยในการทดสอบหน่วยและปัญหาเวลาทำงานกับบริการที่ไม่ได้กำหนดไว้

การฉีด Object Manager เข้าไปในชั้นเรียนนั้นเป็นการฉีด Registry ในชั้นเรียนของคุณซึ่งมีการเข้าถึงบริการแอปพลิเคชันทั้งหมดของคุณซึ่งเห็นได้ชัดว่าไม่ถูกต้อง

ฉันใช้ZF2เป็นธรรมและโดยทั่วไปจะกำหนดคลาสโรงงานขนาดเล็กสำหรับบริการตัวควบคุมและคลาสใด ๆ ที่ต้องการการพึ่งพา คลาสโรงงานเหล่านี้มีการเข้าถึงตัวระบุบริการและคว้าบริการทั้งหมดที่วัตถุขึ้นอยู่กับและแทรกมันผ่านตัวสร้าง การใช้บริการสในระดับโรงงานจะปรับมันเป็นส่วนใหญ่ทิ้งรหัสบางอย่างเช่นนี้ตัวอย่างเช่น

โรงงานเหล่านี้ยังคงทดสอบได้ง่าย

IMO ใช้การสร้างคอนสตรัคที่เป็นไปได้ อีกครั้งฉันไม่รู้มากเกินไปเกี่ยวกับการใช้งาน Magento และถ้ามันมีแนวคิดของโรงงานจากการมองอย่างรวดเร็วมันดูเหมือนว่าจะสนับสนุนพวกเขา แต่การกำหนดชั้นเรียนของคุณอย่างชัดเจนและใช้ Service Locator เพื่อสร้างพวกเขาในคลาสโรงงานคือ แนวทางที่สะอาดกว่ามาก

นี่คือจากคนที่มีการสัมผัสกับ patters ดังกล่าวข้างต้น จำกัด ดังนั้นฉันอยากจะได้ยินความคิด / ประสบการณ์ของผู้อื่นในเรื่อง!

อ่านเพิ่มเติม

• http://ralphschindler.com/2012/10/10/di-dic-service-locator-redux

อีกวิธีหนึ่งในการใช้ตัวช่วย (ในเทมเพลต) คือ:

$this->helper('[Vendor]\[Module]\Helper\[Helper Name]')->getMethodName();

ฉันหวังว่ามันจะมีประโยชน์ถ้าคุณยังไม่รู้

แม้ว่าจะเป็นคำถามเก่า แต่ฉันไม่แน่ใจว่าMariusจะได้รับคำตอบหรือไม่ ฉันเชื่อว่าMariusสามารถตอบได้ดีกว่า ฉันต้องการตอบสั้น ๆ ทำไม Magento 2 แนะนำให้ใช้ DI แทนที่จะเป็นตัวช่วย?

• ทำให้การแยกในการทดสอบหน่วยเป็นไปได้ / ง่าย
• การกำหนดการขึ้นต่อกันของคลาสอย่างชัดเจน
• ยกตัวอย่างเช่นการออกแบบที่ดี (หลักการความรับผิดชอบเดี่ยว (SRP))
• การใช้ DI ในโมดูลของคุณจะช่วยลดความเสี่ยงของข้อบกพร่องที่เข้ากันไม่ได้เมื่อ Magento เปลี่ยนการใช้อินเตอร์เฟซเหล่านั้น นี่เป็นแนวคิดสำคัญที่จะเข้าใจสำหรับนักพัฒนาส่วนขยาย

ทำไม M2 core อาจไม่ใช้ DI ในบางกรณี?

• ลดจำนวนคลาส
• ไม่ได้สร้างอินเทอร์เฟซที่ไม่จำเป็น
• ไม่มีความเสี่ยงจากข้อบกพร่องที่เข้ากันไม่ได้

แม้ว่าโมดูลแคตตาล็อกหลักได้รับการใช้ตัวช่วย แต่ก็ใช้ DI อย่างกว้างขวาง จากการวิจัยของฉันฉันพบว่า Magento 2 ใช้ฟังก์ชั่นบางอย่างในไฟล์ตัวช่วยหลักของแคตตาล็อกซึ่งไม่เหมาะสำหรับสัญญาบริการ

หากคุณต้องใช้คลาสที่กำหนดโดยวีโอไอพีอย่างชัดเจน (เช่น \ Magento \ Catalog \ Model \ Product) ให้ทำการอ้างอิงโดยนัยอย่างชัดเจนโดยขึ้นอยู่กับการใช้งานที่เป็นรูปธรรมแทนที่จะใช้อินเทอร์เฟซสัญญาบริการ

นักพัฒนาส่วนขยายควรใช้ DI แทน Magento1 อย่าง Helper เมื่อดำเนินการตามแนวทางของ Magento 2 fallout นั้นมี จำกัด เมื่อทำลายคำแนะนำปัญหาจะเกิดขึ้น