Avantages du modèle d'usine Magento2 par rapport à Magento 1


15

Magento 2 utilise des classes d'usine pour les non injectables.

Par exemple classe de produit: ProductFactory
Par exemple classe de client:CustomerFactory

Je ne comprends pas quel est le type de modèle d'usine ici?

Parce que pour chaque classe associée à 1 classe d'usine. Je pense que c'est quelque chose en double. Pourquoi ne devrions-nous pas créer une fabrique abstraite pour CustomerFactory, ProductFactoryetc.?

et aussi par exemple:

Nous pouvons passer AbstractFactorypour le type de vérification au lieu de ProductFactorydans le ProductRepositoryconstructeur de classe.

Nous pouvons donc éviter un couplage étroit entre ProductRepositoryetProductFactory


Classe abstraite d'usine:

namespace Magento\Framework\ObjectManager\Code\Generator;

/**
 * Abstract Factory class 
 */
abstract class AbstractFactory 
{
    /**
     * Object Manager instance
     *
     * @var \Magento\Framework\ObjectManagerInterface
     */
    protected $_objectManager = null;

    /**
     * Instance name to create
     *
     * @var string
     */
    protected $_instanceName = null;


    /**
     * Create class instance with specified parameters
     *
     * @param array $data
     * @return \Magento\Catalog\Model\Product
     */
    public function create(array $data = array())
    {
        return $this->_objectManager->create($this->_instanceName, $data);
    }
}

Implémentation de Abstract Factory:

namespace Magento\Catalog\Model;
use Magento\Framework\ObjectManager\Code\Generator\AbstractFactory;
/**
 * Factory class for @see \Magento\Catalog\Model\Product
 */
class ProductFactory extends AbstractFactory
{

    public function __construct(\Magento\Framework\ObjectManagerInterface $objectManager, $instanceName = '\\Magento\\Catalog\\Model\\Product')
    {

        $this->_objectManager = $objectManager;
        $this->_instanceName = $instanceName;
    }

}

Quelle est la relation entre le gestionnaire d'objets et l'usine?

Il y a tellement de chaînage d'objets:

  • Par exemple ProductRepository(ici nous pouvons l'appeler en tant que client) nécessite un Productobjet.

  • Pour cela, cela dépend de l' ProductFactoryobjet spécifique .

  • ProductFactoryl'objet dépend de l' ObjectManagerobjet.

  • ObjectManagerl'objet dépend de l'objet d'usine (ici Developer Object).

Bien sûr, ils utilisent des interfaces pour un couplage lâche. Flux toujours très déroutant.

Pouvez-vous quelqu'un donner des avantages en profondeur avec le modèle d'usine de Magento 2 et aussi comment il diffère de Magento 1?

Réponses:


8

Une chose à retenir est que nous générons automatiquement des classes d'usine UNIQUEMENT SI VOUS NE DÉFINISSEZ PAS UNE PARTIE. Cela signifie que si vous avez besoin de faire de la magie spéciale en usine, vous pouvez le faire. (Par exemple, si vous souhaitez enregistrer chaque création d'une instance pour une raison quelconque, écrivez la fabrique vous-même et nous ne la générerons pas automatiquement.) Si nous utilisions une seule classe de fabrique abstraite pour tout, cela ne fonctionnerait pas.

Cela peut également aider un peu avec le débogage - vous pouvez voir la vraie classe, définir des points d'arrêt, voir des traces de pile plus significatives, etc.


peut être un petit espace..pour la vérification de type uniquement, je veux utiliser la classe abstraite..mais chaque fois que je passe, je veux passer uniquement la classe d'usine béton
sivakumar

Intéressant - j'aurais considéré l'inverse. Je voudrais que CustomerFactory soit transmis, j'ai donc une indication de type que create () renverra Customer. Avec AbstractFactory, je ne peux pas utiliser l'indication de type php Storm pour déterminer le type de l'objet retourné en usine. (Ou est-ce que je manque quelque chose?)
Alan Kent

8

Je peux me tromper ici, mais c'est un avantage que j'ai trouvé.
Les usines générées automatiquement sont quelque peu similaires aux getters ou setters magiques.
Supposons que vous souhaitiez que quelque chose se produise lorsqu'une instance d'une entité spécifique (appelons-la BlogPost) est créée. Supposons que vous souhaitiez définir une valeur par défaut pour un champ.
L'exemple n'est peut-être pas le meilleur, mais écoutez-moi.
Si vous utilisez une fabrique abstraite, vous devrez la modifier de sorte que lorsque vous recevez le nom d'instance en tant que paramètre «BlogPost», vous appelez setDateaprès l'instanciation.

Si vous utilisez la fabrique autogénérée, vous pouvez plus tard créer cette fabrique, appeler le setterdans votre code, supprimer la fabrique générée et cela fonctionnera.
Similaire à ce que vous faites avec le setter magique. Vous implémentez la méthode et elle est appelée partout.


Salut Marius.Merci pour votre réponse.Je suis d'accord avec vous.Vous avez toujours besoin de plus d'informations.
sivakumar

@sivakumar. J'aimerais aussi une réponse d'un membre de l'équipe de base.
Marius
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.