几个星期前，Magento和工程师组成的团队主持的研讨会上Magento2开发更新，它展示了已经做了这么远的Magento2发展，以及什么开发商，商家和解决方案/行业合作伙伴可以期望从它的最终进展启动。在网络研讨会在听我获得了关于主题和布局定制，代码解耦，依赖注入，新的PSR编码标准，以及新的测试基础设施的一些非常有趣的见解。但是，这是什么意思呢？这篇文章将重点介绍和分析了各种开发更新Magento2什么这将意味着在全球Magento的社区。让我们开始吧。
Magento2是一些崇高的目标一个雄心勃勃的项目：
清晰的流程和透明度
提高了产品质量
改进的性能和可扩展性
提高了产品的安全性
增强的模块化架构
网络的API提高覆盖率
简化定制过程和学习曲线
完善多语言支持
改善教育和产品文档，商家和开发人员
对于该项目的详细信息，请访问：Magentocommerce.com这意味着大多数的核心和扩展已重新分解，甚至完全重写，不用说，这已被证明是对的Magento和Magento2团队的一个重大挑战，因为它一直在开发的最后3年也正因为如此很多来自社会最初的激情已经偃旗息鼓。在努力保持参与项目的社区，Magento2代码均可在Github上，2011年，由Magento的可惜这最初的承诺，其次是长时间不活动，其中一些在时间延长了好几个月，导致利息在Magento2死下来了。
随着中说，Magento的终于决定杀青Magento2发展，以及Magento2团队一直在努力，因为几乎十月推出新的代码每周。让我告诉你，我很兴奋（又有点害怕）就进来了，Magento2的变化。
一年前，我贴一下所有来到新变化Magento2，并有自那时以来已经有很多的进步和变化。一个从近期网络研讨会获得的消息是，已经投入Magento的更新使用最新技术的焦点。
这个新版本将只兼容使用PHP 5.4或更高版本。这本身就是一个巨大的变化。到目前为止，Magento的只正式支持最多的PHP 5.3，并同时尝试在较新版本的PHP运行Magento1.x一直比较成功，也有各种众所周知的错误和问题。
那么有很多理由感到兴奋Magento的支持PHP5.4/5.5，但以下是特别有趣：PHP5.4
- 内置在CLI模式开发服务器。
- 支持性状。
PHP5.5
- 集成指令缓存与OPcache扩展。
- 众多改进GD库。
而CLI
web服务器是不是100％的功能与Magento2，可能永远不会，在较新版本的PHP的其他功能都绰绰有余，让开发者兴奋。
如果你还没有被下在PHP世界的最新发展，你可能不知道什么特质，或者为什么他们可以是非常有用的。PHP实现单继承模型，这意味着一个类可能只能从唯一一个类扩展。
像语言C + +和Python的允许从多个类继承，Ruby 在另一方面采用混入到包括来自多个类的功能实际上并没有使用继承。
PHP5.4引入特质，这个概念本身是没有什么新的，是用在像Perl和Scala的语言;特质使我们能够水平重用代码在不同的类中不同的层次。
在思考特质，它有助于它们概念化与实现的接口。如果你不知道什么是接口，你不应该阅读这个博客帖子。
在写这篇文章的时候，Magento2没有实现特征的。但是该选项仍然可以开发他们的扩展和自定义代码中实现它。
让我们不要忘记，PHP5.3现在是4岁和周围的PHP5.3开始显的苍老，特别是当谈到性能较新版本的PHP是更快，可以运行圈。
把这个测试，我下载的脚本从http://www.php-benchmark-script.com/并运行它针对PHP5.3，PHP5.4和PHP5.5，PHP版本：5.3.28 test_math：
1.478秒。
test_stringmanipulation：3.125秒。
test_loops：1.391秒。
test_ifelse：0.954秒。
总时间::
6.948秒
PHP版本：5.4.23
test_math：1.256秒。
test_stringmanipulation：2.868秒。
test_loops：1.057秒。
test_ifelse：0.650秒。
总时间::
5.831秒
PHP版本：5.5.7
test_math：1.068秒。
test_stringmanipulation：2.050秒。
test_loops：0.945秒。
test_ifelse：0.591秒。
总时间::
4.654秒
我们之前的测试是绝不意味着是广泛而深入的，比什么都重要，他们的目的是给我们一个总的想法有关每个版本的总体速度和性能。
我个人会去PHP5.5直接，因为它似乎是有点快，并有一个建立在操作码缓存系统。
相关阅读次数
- PHP 5.4基准
- PHP的路线图和性能
Magento2介绍了它的应用程序结构的许多变化和Magento2的内部功能，但最明显的变化是取消了Mage神类。
许多开发人员都摸不着头脑试图理解为什么Magento是取出使用神类的，毕竟，作为开发人员使用这个调用工厂方法，如Mage:: getModel，Mage:: getSingleton，Mage::Helper，等等。
虽然有一个神级可能是方便的同时也带来了一些问题，如具有较大（难）的依赖在应用程序，这增加了代码的复杂性，使得它不可能弄清楚类的依赖关系，而不会检查源代码。
随着Magento2有一个更大的努力正在作出改进代码质量，并减少代码的复杂性。Mage类的消失也意味着工厂方法和类名都没有了吧。
这将会对开发人员用来与Magento合作的方式显著影响，例如，让我们用一流的产品，更具体地说，类的构造函数作为一个例子，而在Magento1.x它目前看起来是这样的：
|
1
2
3
4
5
6
7
8
9
10
11 |
<?php class Mage_Catalog_Model_Product extends
Mage_Catalog_Model_Abstract{ /** * Initialize resources */ protected
function _construct() { $this->_init(‘catalog/product‘); } |
在Magento2我们有更多的像这样：
|
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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75 |
<?php namespace
Magento\Catalog\Model; class Product extends
\Magento\Catalog\Model\AbstractModel{... /** * @param \Magento\Core\Model\Context $context * @param \Magento\Core\Model\Registry $registry * @param \Magento\Core\Model\StoreManagerInterface $storeManager * @param Product\Url $url * @param Product\Link $productLink * @param Product\Configuration\Item\OptionFactory $itemOptionFactory * @param \Magento\CatalogInventory\Model\Stock\ItemFactory $stockItemFactory * @param ProductFactory $productFactory * @param CategoryFactory $categoryFactory * @param Product\Option $catalogProductOption * @param Product\Visibility $catalogProductVisibility * @param Product\Status $catalogProductStatus * @param Product\Media\Config $catalogProductMediaConfig * @param \Magento\Index\Model\Indexer $indexIndexer * @param Product\Type $catalogProductType * @param \Magento\Catalog\Helper\Image $catalogImage * @param \Magento\Catalog\Helper\Data $catalogData * @param \Magento\Catalog\Helper\Product $catalogProduct * @param Resource\Product $resource * @param Resource\Product\Collection $resourceCollection * @param \Magento\Data\CollectionFactory $collectionFactory * @param array $data * * @SuppressWarnings(PHPMD.ExcessiveParameterList) */ public
function __construct( \Magento\Core\Model\Context $context, \Magento\Core\Model\Registry $registry, \Magento\Core\Model\StoreManagerInterface $storeManager, \Magento\Catalog\Model\Product\Url $url, \Magento\Catalog\Model\Product\Link $productLink, \Magento\Catalog\Model\Product\Configuration\Item\OptionFactory $itemOptionFactory, \Magento\CatalogInventory\Model\Stock\ItemFactory $stockItemFactory, \Magento\Catalog\Model\ProductFactory $productFactory, \Magento\Catalog\Model\CategoryFactory $categoryFactory, \Magento\Catalog\Model\Product\Option $catalogProductOption, \Magento\Catalog\Model\Product\Visibility $catalogProductVisibility, \Magento\Catalog\Model\Product\Status $catalogProductStatus, \Magento\Catalog\Model\Product\Media\Config $catalogProductMediaConfig, \Magento\Index\Model\Indexer $indexIndexer, \Magento\Catalog\Model\Product\Type $catalogProductType, \Magento\Catalog\Helper\Image $catalogImage, \Magento\Catalog\Helper\Data $catalogData, \Magento\Catalog\Helper\Product $catalogProduct, \Magento\Catalog\Model\Resource\Product $resource, \Magento\Catalog\Model\Resource\Product\Collection $resourceCollection, \Magento\Data\CollectionFactory $collectionFactory, array
$data = array() ) { $this->_itemOptionFactory = $itemOptionFactory; $this->_stockItemFactory = $stockItemFactory; $this->_productFactory = $productFactory; $this->_categoryFactory = $categoryFactory; $this->_optionInstance = $catalogProductOption; $this->_catalogProductVisibility = $catalogProductVisibility; $this->_catalogProductStatus = $catalogProductStatus; $this->_catalogProductMediaConfig = $catalogProductMediaConfig; $this->_indexIndexer = $indexIndexer; $this->_catalogProductType = $catalogProductType; $this->_catalogImage = $catalogImage; $this->_catalogData = $catalogData; $this->_catalogProduct = $catalogProduct; $this->_collectionFactory = $collectionFactory; $this->_urlModel = $url; $this->_linkInstance = $productLink; parent::__construct($context, $registry, $storeManager, $resource, $resourceCollection, $data); } |
现在，乍一看Magento2代码可能看起来更糟只是相比于当前版本的代码数量庞大，但如果我们发挥更密切的关注，我们可以看到什么是真正正在做的是一种叫做依赖注入。
在这种情况下，所有的类依赖性都被宣布为作为类的构造函数里面的形式参数，并分配给对象的状态。我们也可以看到，命名空间声明构造函数的属性，这是根据对PSR标准，我们将探讨在后下来以后所做的依赖关系时使用。
一类的依赖关系变得显而易见，只要看看这个类
使用反射类的依赖关系时，可以自动确定
依赖关系可以自动使用依赖注入容器或框架注入
尊重一个真正的面向对象（面向异议）设计
坚持接近固体原则
正如我以前说过，这是最激烈的变化与Magento2来，但它是一个非常积极的，它确实显示了Magento的承诺，以提高代码质量，稳定性和可读性。
话虽这么说，我可以看到许多开发人员使用此功能的变化挣扎，因为这将迫使我们所有的人去思考Magento的代码的改变。
相关阅读次数：依赖注入在PHP中播放
那个一直与Magento的任何数年每个开发人员非常清楚如何很难测试的Magento，以及如何方便是让由于缺乏测试的伤害。Magento2正在做测试和质量改进方面付出巨大的努力，而这些都是组的变化，我真的很期待的。
正如我们前面所看到的，Magento2是消除使用神类和对象，这是用于测试的好消息，因为它允许我们创建真正的单元测试我们的代码。之前，在法师的神对象的广泛依赖（Mage::app（），Mage:: GETCONFIG（），等等）使得它几乎不可能进行测试，因为有硬编码的依赖关系的复杂性，各个功能。
如果这样还不够好，Magento2已建立与测试记住，这个时候测试是从一开始，而不是视为一个想到以后（我MTAF看着你）。该Magento2团队开始通过编写测试其新的重构和变化，他们实现的。
其结果是，在测试框架的一个组成部分Magento2，而且它由包括如下测试类型的非常出色：
集成测试
单元测试
JavaScript的单元测试
静态试验
传统和迁移测试
性能测试
我们不会详细讨论每种类型的测试（但期待以后的文章中涉及到的细节），但最后3种类型是非常有趣的，我们不仅可以测试对Magento的核心功能，但我们也能够测试我们的自定义扩展对系统性能的影响。
不用说，现在的测试是该框架的一个组成部分，编写测试代码定制和扩展，不仅更容易，但值得我们永远做！
Magento的一向真的很难测试，这使得我们的开发工作更加困难，而且容易出错。现在，Magento2已经内置了测试，它可以让我们轻松地添加我们自己的测试，现在没有任何借口的社区扩展到不包括测试！测试是巨大的进步，以提高Magento和它的社区，这将导致更好的代码质量四周，所有的开发和扩展可以有适当的测试他们的代码中受益。这也开辟了可能性TDD（测试驱动开发）的Magento的。
Magento2无疑是一个巨大的飞跃Magento的，这是一个有点一步在技术，性能和编码标准方面的代码发布。它还表明，Magento是致力于不断完善自身，并且该电子商务平台是在这里停留。
原文：http://www.demacmedia.com/magento-commerce/depth-analysis-new-magento2-development-updates/
Magento2发展更新的深入分析,布布扣,bubuko.com
原文：http://www.cnblogs.com/jroy/p/3587586.html