您需要了解的十大Magento 2概念
您需要了解的十大Magento 2概念

您需要了解的十大Magento 2概念

2016年3月31日发布 in 发展历程
现在可在Magento Connect上使用:AddShoppers
2016年3月19日
Magento 2 Dev Docs 优雅的骆马Blog
为Classy Llama为Magento 2做准备’s Dev Docs.
2016年4月13日

您是尚未开始使用Magento 2的Magento开发人员吗?别担心,因为到本文结尾,您已经’确保成为真正的Magento 2专家!

好… perhaps 不. Learning Magento is a hefty task, 后 all, 和 这个 remains 真正 for 版 2 of the platform. A few hundred words aren’显然,这确实会让您起床并运行。但是,如果你’就像我一样,不知道从哪里开始可能是潜水最令人生畏的事情。 真实 本文的目的是向您概述与Magento 1最重要的区别’ll encounter.

 

随着您在新平台上脚踏实地,您可能会惊喜地发现逐行代码的相似性’我会写的真的是。因此,对一些主要建筑概念的一些深入了解将有助于您顺利过渡到Magento 2专家。

在我们真正开始之前,如果您不这样做’还不知道Magento 2有一个 越来越多的文档主题集合 了解更详细的信息。

模块结构

如果你’还不熟悉 作曲家, the resoundingly popular 的PHP dependency manager, now is the time to become so, since the software is 在tegral to the structure of Magento 2. Instead of a single core codebase, Magento is now a collection of 在dividual components 在stalled via 作曲家. This applies to third-party libraries 和 Magento core modules/themes (i.e., packages) alike. Package dependencies have been formalized such that any particular “version” of Magento 能够 真实ly be expressed 在 terms of the 版s of these components 和 their dependencies.

如果你’重新开发可分发的Magento扩展程序,您’还将创建Composer软件包。从更广泛的意义上说,Magento的变化促进了此类自包含组件所需的封装类型’的结构,无论您的代码是市场扩展还是本地定制,都可以简化工作:与模块相关的所有文件现在都位于一个目录中。在Magento 1 的PHP文件中,布局XML,模板和静态资产分散在不同的位置,而单个功能的所有文件现在都在一起。一个模块’s top-level 迪rectory contains the familiar Block, 模型, etc. sub-directories (or 真实ly any sub-directories 在 which you wish to place your 类es), along with a 视图 sub-directory. Within 视图/adminhtml or 视图/frontend are layout 和 template 迪rectories, 和 a web 迪rectory that contains the module’的静态资产,例如JavaScript和CSS。

pub目录和代码生成

存在于许多位置的静态资产文件的概念以及由此引发的问题是进入下一个重要主题的完美选择。自动化的代码生成和部署在Magento 2中扮演着重要的角色,通过查看pub目录可以部分地理解这​​些内容。虽然它’可以使用您的Magento安装’作为开发环境中Web根目录的根目录,生产中必需的Web根目录是新的pub目录,该目录与所有应用程序代码分开存在,并且仅包含Magento放置在其中的内容(包括主应用程序入口点,媒体和静态视图文件) )。由于站点代码现在位于此指定的Web根之外,因此访问控制更加严格和可预测,并且新的部署/编译过程使前面提到的模块封装成为可能:

  • 静态视图文件部署 将所有必要的静态资产从其源代码中的应用程序代码实现到可通过Web访问的pub目录中。此部署过程在开发模式下自动发生,但是在生产中需要明确的操作。资产的这种自动部署使所有JS / CSS代码都可以驻留在其适当的模块中,但仍可以在集中位置通过Web访问。
  • 代码生成 没有’t包含pub目录,但是’与部署概念密切相关。现在,某些类型的PHP类由Magento自动生成,并且比过去更容易实现更细粒度和更轻松的自定义。

依赖注入

依赖注入 在Magento中是一个巨大的话题,所以我’ll cover it 上ly 在 the broadest terms here. Magento 1 had its factory methods that facilitated 类 overrides, like Mage::getModelMage::helper. This is replaced 在 Magento 2 by a more structured approach whereby all external 类型s are 在jected as parameters 在 a 类’的构造函数如下:

的PHP
1
2
3
4
5
6
7
8
9
10
11
12
13
14
.的PHP
 
{
受保护的 $ 请求;
受保护的 $ 客户帐户管理;
上市 功能 __构造(
\Magento\构架\应用程式\请求\Http $ 请求,
\Magento\顾客\阿皮\帐户管理接口 $ 客户帐户管理
) {
$ 这个->请求 = $ 请求;
$ 这个->客户帐户管理 = $ 客户帐户管理;
}
}

这种方式引用的类型由Magento自动实例化并传递’的对象管理器。这有助于使用真实的类名和PHP名称空间,而不是使用专有的工厂方法来乱扔代码,它通过集中化对依赖项的引用来使代码更有条理,并且允许使用更灵活的方法来覆盖类。请注意,在上面的代码中,一个依赖项仅引用一个接口,而不引用完整的类。接口是Magento 2的重点重点,并且依赖 优先 在特殊的配置文件中定义– 迪.xml –指定此类接口的最佳默认实现。该DI配置是第三方模块用来全局更改默认接口或完整类的首选项的工具(等效于Magento 1’s类重写)或针对特定上下文(通过在构造函数中进行集中实现)。通过构造函数注入获得的外部类是共享实例(即“singleton”模式),并称为“injectables.”

外挂程式

如前所述,Magento 1类重写可以在指定依赖项注入首选项的过程中找到其类似物。我还提到,借助M2,更多的个性化定制技术成为可能’的代码生成,以及 外挂程式 是最重要的例子。插件使您可以更改或扩展目标方法,而无需替换整个类。

Like 优先, 外挂程式 are defined 在 迪.xml files, 和 they have specific “before,” “after” 和 “around”实现,分别允许您更改原始方法的输入,对它的输出进行进一步操作,或者使用自己的逻辑将其包围。最好的是,可以用一种方法定义多个插件,从而大大提高了在系统同一区域上运行的扩展之间的兼容性。 M2’的代码生成和对象管理器负责按正确的步调运行方法调用,并在必要时将其移交给插件。以下是插件定义和实现的本地示例:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
.XML文件
 
<类型 名称=“ Magento \ Store \ 模型 \ 资源模型 \ Group”>
    <插入 名称=“ categoryStoreGroupAroundSave” 类型=“ Magento \目录\模型\索引器\类别\产品\插件\存储组”>
</类型>
 
 
--
 
店铺组.的PHP
 
店铺组
{
    上市 功能 周围Save(
        \Magento\构架\模型\资源模型\D b \抽象数据库 $学科,
        \关闭 $继续,
        \Magento\构架\模型\抽象模型 $
    ) {
        $needInvalidating = $这个->验证($);
        $objectResource = $继续($);
        如果 ($needInvalidating) {
            $这个->在dexerRegistry->得到(\Magento\目录\模型\索引器\类别\产品::INDEXER_ID)->使无效();
        }
 
        返回 $objectResource;
    }
}

工厂工厂

关于依赖项注入,您可能已经注意到一个重大遗漏。“Injectables,”作为共享实例对象,实际上相当于M1’s Mage::getSingleton factory technique. So where is the equivalent of the Mage::getModel factory method for obtaining unique object 在stances (that is, “non-injectables”以M2的说法)?此类对象使用专用于此目的的可注入类实例化: 工厂。遵循以下使用工厂类实例化模型的方式:

的PHP
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
.的PHP
 
{
    受保护的 $ 客户工厂;
    上市 功能 __构造(
        \Magento\顾客\模型\客户工厂 $ 客户工厂
    )
    {
        $ 这个->客户工厂 = $ 客户工厂;
    }
    
    上市 功能 得到Customer($ email)
    {
        返回 $ 这个->客户工厂->创建()->loadByEmail($ email);
    }
}

您对上述内容的第一个反应可能是认为定义和维护一个类以处理实例化另一个类似乎很麻烦。在这方面,M2的好处’的代码生成再次得到拯救,因为工厂类实际上并没有’完全不需要定义。它们会在遇到这样的工厂时由Magento自动创建。特定于类的方法意味着您 能够 但是,可以明确定义它们,从而在必要时方便地为任何特定类定制工厂技术。

服务层

像依赖注入一样,服务层本身值得一整套的文章(请参阅有关服务的核心文档) 合约设计模式),但只需稍作解释即可掌握基本概念。考虑到Magento 1中自定义的主要挑战之一是代码几乎可以肯定地依赖于核心Magento类的特定实现细节,并且对该核心代码的重大更改(例如方法参数或逻辑的更改)可能会使自定义代码无法操作。 M2服务层通过在模块的主要业务逻辑和引用该模块的任何外部代码之间引入一个层来缓解此问题。’s components. “Service 合约”采用严格定义实体的接口的形式以及外部代码与实体进行交互的规定方式;这些接口以及从服务层实现它们的类。

例如,让’s consider the core 顾客 entity. Magento\Customer\Model\Customer is the model for a customer entity, 和 这个 类 has corresponding resource 和 collection models that serve the same purpose as their M1 counterparts. Rather than reference these 类es 迪rectly, however, external modules should utilize a sort of traffic controller 类 called Magento\Customer\Model\ResourceModel\CustomerRepository to obtain 和 manipulate 在stances of Magento\Customer\Model\Data\Customer. Both 类es implement service contract 在terfaces, 和 while they use the typical data 和 collection models under the hood, the methods exposed 在 the 在terfaces make 这个 implementation 在visible 和 explicitly define the details external code 能够 rely 上. The logic of models 和 collections may change to any degree 在 the future, but the details of the service 合约 will remain the same, preserving the compatibility of custom modules.

Service contract 在terfaces are located 在 the API sub-directory of a module. 如果你’重新生成可分发的代码,强烈建议您为自己的实体创建服务合同和类,以保持与其他实体的未来兼容性’ code.

页面缓存

在Magento 1中,全页缓存是Enterprise独有的性能增强功能,而将其容纳在您自定义开发的功能中并不是最琐碎的开发主题。在M2中,全页缓存是Community和Enterprise的一项功能,位于Magento_PageCache模块中,它对开发人员的影响要更加简化。

全页缓存的主要挑战是网页的某些区域,其内容不能对所有访问者和页面视图都通用。 M1专注于为最终HTML输出渲染的一部分组装这些区域的内容,而M2则采用了不同的方式–越来越受欢迎–方法。首先,应将应与主缓存内容解耦的页块更可靠地定义为“private data”:取决于访问者的内容’s session 在formation. Secondly, such blocks are anonymized for all visitors 在 the 在itial rendering of the page, with the 私人数据 在stead loaded via an Ajax 请求 后 the main page 内容 is delivered. Thus, the main body of a page is cached 和 delivered as swiftly as possible, with less essential 和 visitor-specific 内容 materializing asynchronously.

In terms of the implications for developers, accommodating the page cache is almost 在sanely simple as compared with M1. Marking a block as 私人数据 is as simple as setting a single property, 和 Magento takes care of the rest:

的PHP
1
2
3
4
5
6
7
8
9
10
示例块.的PHP
 
示例块
{
    上市 功能 __构造()
    {
        父母::__构造();
        $ 这个->_isScopePrivate = 真正;
    }
}

CSS编译

自从对其主题进行响应式大修以来,以SASS / Compass形式进行的CSS编译已成为Magento 1的一部分。Magento 2中选择的工具是LESS,它具有几乎相同的功能,包括CSS变量,可重复的样式,包含的多文件组织等等。

覆盖 M2中LESS的细节 不在本文的讨论范围之内,但是要掌握的重要概念是M2开发人员如何处理CSS编译(或更准确地说,是 处理)。在M1中’作为响应主题,编译是Magento应用程序完全看不见的过程。开发人员负责将源代码编译成最终的CSS文件,然后像以往一样通过布局将其明确包含在内。在M2中,作为上述静态文件部署过程的一部分,在应用程序级别完成CSS编译魔术。只需确保将LESS源文件包含在适当的位置,Magento将负责其余的工作。 (它’值得注意的是’仍然有利于编译 在开发过程中有所不同,但关键是该过程已高度集成到应用程序核心中。)

Any underscore-prefixed source files placed 在 the 视图/{area}/web/css/source 迪rectory of a module or the web/css/source 迪rectory of a theme will be compiled 在to the main styles, with 上ly a single 在stance of a unique 名称 being loaded site-wide, depending upon a priority order (thus allowing for override of specific partials). On top of 这个, the magically 名称d _module.less_widgets.less (for modules) 和 _extend.less (for themes) allow styles to be cumulative 在stead of 迪rectly overriding the identically 名称d partials from other sources.

JavaScript包含和RequireJS

Magento 2从传统的方法(包括将每个带有标签的JS文件明确要求“include-as-needed”主要利用的方法 需求JS。 (看到 这一页 (有关Magento中RequireJS的信息。)RequireJS是一个强大的工具,具有自己的文档,但要了解的重要一点是,它允许将JavaScript封装在声明依赖项的外壳中,然后由RequireJS管理加载。这样可以确保仅在需要时以必要的顺序加载JavaScript组件。

The process could almost be considered a JS 版 of dependency 在jection, 和 there are 几种方法 在Magento。这里’一个简单的例子,它需要组件“mage/url”作为机箱内代码的依赖项,传入该文件返回的类作为函数的参数:

1
2
3
4
5
6
7
8
9
.phtml
 
<script>
    要求([
        '法师/网址'
    ], 功能(网址) {
        返回 网址.setBaseUrl('http://www.mydifferentdomain.com');
    })
</script>

Magento引入的其他两种方式可以立即确定对特定选择器的jQuery插件的范围,可以在Magento文档页面上进行研究。命名组件位置的精确定义是在一个名为requirejs-config.js的每个模块文件中设置的,并且像依赖注入一样,此配置允许通过将组件定义替换为您自己的组件来轻松扩展和覆盖组件。

JavaScript组件

建议大量使用JavaScript的开发人员不仅熟悉包括JS代码的技术,而且要熟悉Magento对自己的JavaScript采取的一些功能强大的系统化方法。首先,它’值得注意的是,M2大量使用了jQuery UI库及其自己的自定义小部件中的jQuery小部件。当你’在重新开发JS繁重的接口时,同样值得在您自己的代码中利用此模式。

一个更复杂的主题是JS类uiComponent(与M2不同’s UI组件 库)以及布局,JS和静态模板可以一起使用的方式。在这种范例中,扩展uiComponent的JS组件可以通过布局XML进行初始化,并将配置传递给它们。在此配置中可以定义用于呈现组件的静态模板路径,该路径通过Ajax加载而无需PHP的参与,并且包含 昏死 语法以动态访问JS组件公开的属性和方法。掌握此特定模式将对Magento的核心用法和Knockout的功能进行一些研究,但这是示例的最佳片段:

1
2
3
4
5
6
7
8
默认.XML文件
 
<项目 名称=“ 小车_content” si:类型=“数组”>
    <项目 名称=“零件” si:类型=“串”>Magento_结帐 /js/视图/小车</项目>
    <项目 名称=“配置” si:类型=“数组”>
        <项目 名称=“模板” si:类型=“串”>Magento_结帐 /小车/内容</项目>
    </项目>
</项目>

How the above fits 在to the layout structure 和 how its 父母 block 在itializes such components is beyond what I 能够 cover 在 such limited space. However, know that the above defines the path to the JS file that represents 这个 component (小车.js, containing a 类 that extends uiComponent) 和 a static template file loaded straight from the server (内容.html), which contains 昏死 code referencing logic from 小车.js.

Magento 2中还有很多其他较小的体系结构更改,您可能会提到’随着您对新平台的小型投资变成大型企业,他们将变得非常熟悉。但是,对于正在寻找起点的开发人员,以上主题代表了一些最佳的方法,您可以利用它们来花费Magento 2培训时间。开始了解这些概念,您’确保开始将M2视为热情的朋友,而不是不祥的陌生人。

2 评论s

  1. 克尔·沙(Keyur Shah) 说:

    谢谢,那个’关于magento的概述!

  2. 耶兹劳 说:

    Great overview. Still so hard to switch 后 years of loving M1 with lots of complex 在tegrations working. It’就像重新重做网站一样,即使它’确实不需要重做。也许我们’ll从现在开始升级10年。 *叹*

发表评论 取消回复

您的电子邮件地址不会被公开。 必需的地方已做标记 *

该网站使用Akismet减少垃圾邮件。 了解如何处理您的评论数据.

最近的帖子查看全部
2020年10月22日
通过 阿什莉·科利弗 商业见解, 优雅的骆马 2020年10月22日
毫无疑问,2020年是历史性的一年。火灾,全球大流行,暴动,老虎王等’只是冰山一角。如 […]