magento企业版安装_magento 2旧版orm解释

magento企业版安装

Magento Officials are telling that Magento 2 has modern ORM. It is not a modern end even not an ORM. It is a beast… Let’s check why Magento 2 is peace of outdated PHP code.

Magento官员告诉Magento 2具有现代ORM。 这不是现代目的，甚至不是ORM。 这真是野兽……让我们检查一下为什么Magento 2是过时PHP代码。

Wiki describes ORM like:

Wiki对ORM的描述如下：

Object-relational mapping (ORM, O/RM, and O/R mapping tool) in computer science is a programming technique for converting data between incompatible type systems using object-oriented programming languages. This creates, in effect, a “virtual object database” that can be used from within the programming language.

计算机科学中的对象关系映射( ORM ， O / RM和O / R映射工具)是一种使用面向对象的编程语言在不兼容类型系统之间转换数据的编程技术。 实际上，这将创建一个“虚拟对象数据库”，可以从编程语言中使用它。

Compared to traditional techniques of exchange between an object-oriented language and a relational database, ORM often reduces the amount of code that needs to be written. However, with Magento 2 you will need to write a lot of copy-paste code from the Stack Overflow.

与面向对象的语言和关系数据库之间的传统交换技术相比，ORM经常减少需要编写的代码量。 但是，使用Magento 2，您将需要从Stack Overflow中编写很多复制粘贴代码。

What are the advantages of using modern ORM

使用现代ORM有什么优势

1. It abstracts away the database system so that switching from MySQL to PostgreSQL, or whatever flavor you prefer, is easy-peasy.
   它抽象化了数据库系统，以便轻松地从MySQL切换到PostgreSQL或您喜欢的任何口味。
2. With the modern ORM, you get a lot of advanced features out of the box, such as support for transactions, connection pooling, migrations, seeds, streams, and all sorts of other goodies. With Magento legacy code you don’t have these features
   借助现代的ORM，您可以立即获得许多高级功能，例如对事务，连接池，迁移，种子，流以及各种其他功能的支持。 使用Magento旧代码，您将没有这些功能
3. Many of the queries you write with the modern ORM will be optimized and perform better than if you wrote them yourself.
   与您自己编写的查询相比，您使用现代ORM编写的许多查询将得到优化并提高性能。

Magento 2 doesn’t have all these features it has just an abstraction over Raw SQL queries (Resource model)

Magento 2不具有所有这些功能，它只是对Raw SQL查询的一种抽象(资源模型)

Martin Fauler in his book Patterns of Enterprise Application Architecture (Originally published: November 5, 2002) describes Magento 2 ORM pattern Data Mapper:

Martin Fauler在他的《企业应用程序体系结构的模式》一书中(最初出版：2002年11月5日) 描述了Magento 2 ORM模式数据映射器：

Objects and relational databases have different mechanisms for structuring data. Many parts of an object, such as collections and inheritance, aren’t present in relational databases. When you build an object model with a lot of business logic it’s valuable to use these mechanisms to better organize the data and the behavior that goes with it. Doing so leads to variant schemas; that is, the object schema and the relational schema don’t match up. You still need to transfer data between the two schemas, and this data transfer becomes a complexity in its own right. If the in-memory objects know about the relational database structure, changes in one tend to ripple to the other. The Data Mapper is a layer of software that separates the in-memory objects from the database. Its responsibility is to transfer data between the two and also to isolate them from each other. With Data Mapper the in-memory objects needn’t know even that there’s a database present; they need no SQL interface code, and certainly no knowledge of the database schema. (The database schema is always ignorant of the objects that use it.) Since it’s a form of Mapper (473), Data Mapper itself is even unknown to the domain layer. How It Works The separation between domain and data source is the main function of a Data Mapper, but there are plenty of details that have to be addressed to make this happen. There’s also a lot of variety in how mapping layers are built. Many of the comments here are pretty broad, because I try to give a general overview of what you need to separate the cat from its skin.

对象和关系数据库具有不同的数据结构机制。 关系数据库中不存在对象的许多部分，例如集合和继承。 当您使用许多业务逻辑构建对象模型时，使用这些机制来更好地组织数据及其伴随的行为非常有价值。 这样做会导致方案变型。 也就是说，对象模式和关系模式不匹配。 您仍然需要在两个模式之间传输数据，这种数据传输本身就变得很复杂。 如果内存中的对象知道关系数据库的结构，则其中一个的更改往往会波及到另一个。 数据映射器是将内存中对象与数据库分开的软件层。 它的职责是在两者之间传输数据，并使它们彼此隔离。 使用Data Mapper，即使存在数据库，内存对象也无需知道； 他们不需要SQL接口代码，当然也不需要数据库架构的知识。 (数据库模式始终不了解使用该数据库模式的对象。)由于它是Mapper的一种形式(473)，因此Data Mapper本身甚至对于域层也是未知的。 工作原理域和数据源之间的分离是Data Mapper的主要功能，但是要实现这一点，必须解决许多细节。 构建映射图层的方式也多种多样。 这里的许多评论都相当广泛，因为我试图大致概述将猫与猫分开的必要条件。

Magento's “Data MAper” ORM is a tool that abstracts SQL queries for you using Zend Framework 1 Zend/Db adapter - a legacy mess that leads to more accidental bugs down the line.

Magento的“ Data MAper” ORM是使用Zend Framework 1 Zend / Db适配器为您抽象SQL查询的工具，这是一种传统混乱，会导致更多意外错误。

Zend\Db has some good abstractions for the Table-Data-Gateway pattern, and that part is mostly fine for MyISAM. When applied to modern InnoDB MySQL applications with foreign keys and such, using Zend\Db still leads to “table-oriented-software-development”, because developers have to:

Zend \ Db对Table-Data-Gateway模式有一些很好的抽象，而那部分对于MyISAM来说通常是很好的。 当将Zend \ Db应用于具有外键等的现代InnoDB MySQL应用程序时，使用Zend \ Db仍然会导致“面向表的软件开发”，因为开发人员必须：

• manually reason about foreign key constraint
  关于外键约束的手动原因
• manually fetch dependencies of a previous fetch: no lazy-loading — not that lazy-loading is necessarily a good thing, but that makes everything much more complex
  手动获取先前获取的依赖项：没有延迟加载-并不是说延迟加载不一定是一件好事，但这会使一切变得更加复杂
• reason about object state rather than object behavior: very few developers understand that objects should have behavior before fields, and Zend\Db is designed around saving/loading fields manually via hydration.
  关于对象状态而不是对象行为的原因：很少有开发人员了解对象应该在字段之前具有行为，并且Zend \ Db是围绕通过水合作用手动保存/加载字段而设计的。

Then there is Zend\Db\Select, which is just a nightmare to work with: everything smashed, making things extremely hard to read, maintain, and refactor. Also, Zend_DB is not an actively maintained library anymore it reached its END off life (28 September 2016) many years ago. However, overwrite Magento 1 legacy to something modern was expansive so Magento 2 just using it as is and selling this outdated legacy solution for non educated merchants as a “modern” and “innovative” solution…

然后是Zend \ Db \ Select，这只是一场噩梦：所有东西都被粉碎了，使事情变得极难阅读，维护和重构。 而且，Zend_DB不再是一个主动维护的库，它在很多年前就已经寿终正寝(2016年9月28日)。 但是，将Magento 1的遗产覆盖为现代的东西是很广泛的，因此Magento 2只是按原样使用它，并且将这种过时的遗产解决方案作为“现代”和“创新”解决方案出售给未受过教育的商人...

When we are using Core Magento Models with not optimized queries and code instead of writing SQL with good performance, it is easy not to realize that a big number of requests can be executed.Magento ORM gives us a “productRepository” that helps to fetch Products. Magento code looks like:

当我们使用没有优化查询和代码的Core Magento模型而不是编写具有良好性能SQL时，很容易不意识到可以执行大量请求。MagentoORM为我们提供了一个“ productRepository”，可帮助获取产品。 Magento代码如下所示：

function _getAssociatedProducts() {
$ids = $this->getProduct()->getAssociatedProductIds();
foreach ($ids as $id) {
$prods[] = $this->productRepository->getById($id);
}
return $prods;
}

What's happening here?Let’s say we fetch 100 product ids.For each product, we want to fetch the associated. So we will call the product model getById 100 times!This very simple code is actually performing 100 + 1 queries! (“N+1” problem).Of course, In pure SQL, we could solve this in exactly one query! In theory but not for product model because of EAV design.

假设我们要获取100个产品ID，对于每个产品，我们都希望获取关联的产品。 因此，我们将产品模型getById调用100次！这个非常简单的代码实际上执行了100 + 1个查询！ (“ N + 1”问题)。当然，在纯SQL中，我们可以在一个查询中解决这个问题！ 从理论上讲，但由于EAV设计，不适用于产品模型。

Take a look at how Magento Collection from 5 elements profiling timeline looks like:

看一下来自5个元素分析时间轴的Magento Collection如何：

SQL trace:

SQL跟踪：

1. Catalog Product Entity Request

1.目录产品实体请求

SELECT
  catalog_product_entity.*
FROM
  catalog_product_entity
WHERE
  ((entity_id = ?))
  AND (catalog_product_entity.created_in ?)

2. Catalog Product Entity Request I don’t know why it has to 2 times the same request however nobody actually knows how this legacy works. If you know please leave a comment

2.目录产品实体请求我不知道为什么它必须是同一请求的2倍，但是实际上没有人知道这种继承的工作方式。 如果您知道，请发表评论

SELECT
  t.*
FROM
  catalog_product_entity AS t
WHERE
  ((entity_id = ?))
  AND (t.created_in ?)

3. Media Gallery Request has its own type of EAV

3. Media Gallery Request具有自己的EAV类型

SELECT
 u.*
FROM
 (..) AS u
ORDER BY
 store_id ASCSELECT
  main.value_id,
  main.value AS file,
  [..]
FROM
  catalog_product_entity_media_gallery AS main
  INNER JOIN catalog_product_entity_media_gallery_value_to_entity AS entity ON main.value_id = entity.value_id
  LEFT JOIN catalog_product_entity_media_gallery_value AS value ON main.value_id = value.value_id
  AND value.store_id = ?
  AND value.row_id = entity.row_id
  LEFT JOIN catalog_product_entity_media_gallery_value AS default_value ON main.value_id = default_value.value_id
  AND default_value.store_id = ?
  AND default_value.row_id = entity.row_id
  LEFT JOIN catalog_product_entity_media_gallery_value_video AS value_video ON value.value_id = value_video.value_id
  AND value.store_id = value_video.store_id
  LEFT JOIN catalog_product_entity_media_gallery_value_video AS default_value_video ON default_value.value_id = default_value_video.value_id
  AND default_value.store_id = default_value_video.store_id
WHERE
  (main.attribute_id = ?)
  AND (main.disabled = ?)
  AND (entity.row_id = ?)
ORDER BY
  IF(
    value.position IS NULL,
    default_value.position,
    value.position
  ) ASCSELECT
  catalog_category_product.category_id,
  catalog_category_product.position
FROM
  catalog_category_product
WHERE
  (product_id = ?)

4. Website ID query

4.网站ID查询

SELECT
  catalog_product_website.website_id
FROM
  catalog_product_website
WHERE
  (product_id = ?)

5. Tire Price Request catalog_product_entity_tier_price

5.轮胎价格请求catalog_product_entity_tier_price

SELECT
  catalog_product_entity_tier_price.value_id AS price_id,
  catalog_product_entity_tier_price.website_id,
  [..]
FROM
  catalog_product_entity_tier_price
WHERE
  (website_id = ?)
  AND (row_id = ?)
ORDER BY
  qty ASC

6. Catalog Inventory Query

6.目录库存查询

SELECT
  main_table.*,
  cp_table.type_id
FROM
  cataloginventory_stock_item AS main_table
  INNER JOIN catalog_product_entity AS cp_table ON main_table.product_id = cp_table.entity_id
  AND (cp_table.created_in ?)
WHERE
  (main_table.product_id IN ([..]))

7. URL rewrite per product

7.每个产品的URL重写

SELECT
  url_rewrite.*,
  relation.*
FROM
  url_rewrite
  LEFT JOIN catalog_url_rewrite_product_category AS relation ON url_rewrite.url_rewrite_id = relation.url_rewrite_id
WHERE
  (url_rewrite.entity_id IN ([..]))
  AND (url_rewrite.entity_type IN ([..]))
  AND (url_rewrite.store_id IN ([..]))
  AND (relation.category_id IS NULL)

8. There it is! Magento 2 EAV request. The query is too long that uses more network traffic then product image

8.那里！ Magento 2 EAV请求。 查询时间过长，与产品图片相比使用的网络流量更多

SELECT `u`.* FROM (
(SELECT `t`.`value`, `t`.`attribute_id`, `t`.`store_id` 
FROM  `catalog_product_entity_int` AS `t` 
WHERE (row_id = '?') AND (attribute_id IN ([..])) 
AND (`store_id` IN (1, 0)))
UNION ALL(SELECT `t`.`value`, `t`.`attribute_id`, `t`.`store_id` FROM `catalog_product_entity_varchar` AS `t` 
WHERE (row_id = '?') AND (attribute_id IN ([..])) 
AND (`store_id` IN (1, 0)))
UNION ALL(SELECT `t`.`value`, `t`.`attribute_id`, `t`.`store_id` FROM `catalog_product_entity_text` AS `t` WHERE (row_id = '?')
 AND (attribute_id IN ([..])) 
AND (`store_id` IN (1, 0))) 
UNION ALL(SELECT `t`.`value`, `t`.`attribute_id`, `t`.`store_id` FROM `catalog_product_entity_decimal` AS `t` 
WHERE (row_id = '?') AND (attribute_id IN ([..])) 
AND (`store_id` IN (1, 0)))
UNION ALL(SELECT `t`.`value`, `t`.`attribute_id`, `t`.`store_id` FROM `catalog_product_entity_datetime` AS `t` 
WHERE (row_id = '?') AND (attribute_id IN ([..])) 
AND (`store_id` IN (11, 0))) ) AS `u` 
ORDER BY `store_id` ASC

Important: UNION is defined that way in SQL. Duplicates must be removed and this is an efficient way for the MySQL engine to remove them. Combine results, sort, remove duplicates, and return the set. Queries with UNION can be accelerated in two ways. Switch to UNION ALL or try to push ORDER BY, LIMIT, and WHERE conditions inside each subquery. And I’m glad Magento 2 has this optimization.

重要说明：在SQL中，UNION是通过这种方式定义的。 必须删除重复项，这是MySQL引擎删除重复项的有效方法。 合并结果，排序，删除重复项，然后返回集合。 使用UNION的查询可以通过两种方式来加速。 切换到UNION ALL或尝试在每个子查询中推送ORDER BY，LIMIT和WHERE条件。 我很高兴Magento 2有了这种优化。

9. Product Option Table

9.产品选件表

SELECT
  main_table.*,
  tdv.value AS default_value,
  [..]
FROM
  eav_attribute_option AS main_table
  INNER JOIN eav_attribute_option_value AS tdv ON tdv.option_id = main_table.option_id
  LEFT JOIN eav_attribute_option_value AS tsv ON tsv.option_id = main_table.option_id
  AND tsv.store_id = ?
  LEFT JOIN eav_attribute_option_swatch AS sw ON main_table.option_id = sw.option_id
WHERE
  (main_table.attribute_id = ?)
  AND (tdv.store_id = ?)
  AND (main_table.option_id = ?)
GROUP BY
  option_id
ORDER BY
  main_table.sort_order ASC,
  value ASC

10. Customer Group Product Price

10.客户组产品价格

SELECT
  catalogrule_product_price.product_id,
  catalogrule_product_price.rule_price
FROM
  catalogrule_product_price
WHERE
  (rule_date = ?)
  AND (website_id = ?)
  AND (customer_group_id = ?)
  AND (product_id IN ([..]))

10+ MySQL queries per single product in the Magento 2 collection! For 20 products per page, you will have 200 queries. Don’t trust? Check it yourself.

Magento 2集合中的每个产品10个以上MySQL查询！ 对于每页20个产品，您将有200个查询。 不信任吗自己检查一下。

类别页面产品集合概要分析的示例： (Example of the category page product collection profiling:)

So, during the execution of Magento 2 Models and Collections, we looked at automatically generated Magento SQL queries using XHProf profiler. We discovered that Magento ORM generated multiple SQL-queries for each table and each product of the collection instead of joining or uses IN sql condition in the query. Because of this, it creates performance problems for Magento ORM. Raw SQL performed with optimized query performed much better than Magento 2 ORM.

因此，在执行Magento 2模型和集合期间，我们研究了使用XHProf分析器自动生成的Magento SQL查询。 我们发现Magento ORM为每个表和集合的每个产品生成了多个SQL查询，而不是在查询中加入或使用IN sql条件。 因此，它为Magento ORM带来了性能问题。 与优化查询一起执行的原始SQL的性能比Magento 2 ORM好得多。

And what The Magento 2 architects are telling about that? It is new normal now, best practices. It is a new technology MOP — Magento Obfuscated Programing.

Magento 2架构师在讲什么呢？ 现在这是新常态，最佳做法。 它是一种新技术MOP-Magento混淆编程。

Modern ORM solutionsModern ORM has solutions — Eager (loading process whereby a query for one type of entity also loads related entities as part of the query).

现代ORM解决方案现代ORM具有解决方案-渴望(加载过程，一种类型的实体的查询也将相关实体作为查询的一部分进行加载)。

Unfortunately, Magento using legacy PHP ZF1 and doesn't follow the best software development practices. Who cares. Mostly Magento 2 is sales for not technically educated merchants and outsource PHP developers.

不幸的是，Magento使用旧版PHP ZF1并没有遵循最佳软件开发实践。 谁在乎。 大多数情况下，Magento 2的销售对象是没有受过技术教育的商人，并且外包了PHP开发人员。

相同Magento 2代码的Laravel示例： (Laravel Example of the same Magento 2 code :)

$products = Product::with(‘associatedProducts’)->get();foreach ($products as $product) {
        echo $user->associatedProducts->url;
}

This code snippet will generate optimized single or 2 SQL queries instead of 100–1000 queries in the case of the Magento 2 Resource Model.

对于Magento 2资源模型，此代码段将生成优化的单个或2个SQL查询，而不是100–1000个查询。

Magento 2“ ORM”与现代ORM的另一个实际示例 (Another practical example of the Magento 2 “ORM” vs modern ORM)

Magento 2 Join:

Magento 2加入：

$order->getSelect()->join(
    [
       ‘payment’ =>’sales_order_payment_table’], 
       ‘sales_order_table .entity_id= payment.parent_id’,
    [
       ‘payment_method’ => ‘payment.method’,
       ’order_id’ => ‘sales_order_table.entity_id’
    ]
);

Laravel Join:

Laravel加入：

$order = Order::with([‘payment’,’method’])->all();

What version do you like more?

您更喜欢哪个版本？

Magento legacy collections

Magento旧版收藏

Modern ORM doesn’t have a different between collection and model. Collections crates automatically when you are selecting more than one row from the DB.

现代ORM在集合和模型之间没有区别。 当您从数据库中选择多个行时，收集箱将自动创建。

All multi-result sets returned by ORM are Collection objects, including results retrieved via the get method or accessed via a relationship.

ORM返回的所有多结果集都是Collection对象，包括通过get方法检索或通过关系访问的结果。

$users = App\Models\User::where(‘active’, 1)->get();

$ users = App \ Models \ User :: where('active'，1)-> get();

No needs to execute getCollection() to write SQL query.

无需执行getCollection()即可编写SQL查询。

Magento 2 collections and Repositories can get really big (new products, customers, categories, lots of attributes etc.) and become really difficult to work with.

Magento 2集合和存储库可能变得非常庞大(新产品，客户，类别，许多属性等)，并且变得很难使用。

Magento collections work only for smaller collections, but with large ones, the script will eventually run out of memory and produce the following error:

Magento集合仅适用于较小的集合，但是对于较大的集合，脚本最终将耗尽内存并产生以下错误：

“Fatal error: Allowed memory size of X bytes exhausted (tried to allocate X bytes) in”

“致命错误：允许的X字节已用尽的内存大小(尝试分配X字节)”

Magento collection is basically an array of objects. The more objects we have and the more attributes we add to selection, the bigger the resulting array will be, which leads to high memory usage. Also, Magento 2 is adding redundant garbage to each object. Just check XDebug of the real object or just make Var_Dump.

Magento集合基本上是一组对象。 我们拥有的对象越多，选择中添加的属性越多，结果数组将越大，从而导致较高的内存使用率。 同样，Magento 2正在向每个对象添加冗余垃圾。 只需检查实际对象的XDebug或仅创建Var_Dump。

var_dump at all does not work well with Magento 2

var_dump根本不适用于Magento 2

It tries to print the Magento object and this object has a lot of objects attached to it because of the dependency injection. Each object has additional objects linked to it.

它尝试打印Magento对象，并且由于依赖项注入，该对象具有许多附加的对象。 每个对象都有与其链接的其他对象。

var_dump won’t work for most of the objects in Magento 2…

var_dump不适用于Magento 2中的大多数对象…

That’s why Indexer and Import functionality doesn’t use models directly.

这就是为什么索引器和导入功能不直接使用模型的原因。

Legacy ORM patterns

旧版ORM模式

For the web application, Magento 2 is a massive over engendered system. It’s ORM forces you to use EAV model to do even simple things.

对于Web应用程序，Magento 2是一个庞大的过度生成系统。 ORM迫使您使用EAV模型甚至做简单的事情。

For example, just to retrieve 5 simple products from a database that have a price in the range of $100–$300 you would most likely spend 1–4 hours trying to work out the query. This SQL query will take 100500 lines.

例如，仅从数据库中检索5个价格在$ 100- $ 300之间的简单产品，您很可能会花费1-4个小时来尝试查询。 此SQL查询将占用100500行。

EAV sounds great, in reality, it slows things down with all those multiple JOINS executed on the database in the different calls.

实际上，EAV听起来不错，它可以通过在不同调用中在数据库上执行的所有多个JOINS来减慢速度。

The EAV model is great in theory and is probably great in practice if the backing software has been designed with EAV in mind.

如果支持软件是在考虑EAV的情况下设计的，那么EAV模型在理论上很好，在实践中也可能很棒。

In the context of Magento 2, it is a real nightmare and is one of the major contributors to the slowness of the Magento platform.

在Magento 2的背景下，这是一场真正的噩梦，并且是Magento平台运行缓慢的主要因素之一。

The reason for this slowness is that in a relational database, the EAV model needs multiple gigantic queries with tons of JOINs.

这种缓慢的原因是，在关系数据库中，EAV模型需要使用大量的JOIN进行多个巨大的查询。

To give you an example, querying a product in Magento may need to join no less than 11 tables!

举个例子，在Magento中查询产品可能需要联接不少于11个表！

In theory, choosing to use the NoSQL EAV approach was an amazing idea. In practice, this idea did not scale for large Magento stores and it has made Magento 2 hugely complex, slow, and hard to use.

从理论上讲，选择使用NoSQL EAV方法是一个了不起的主意。 在实践中，这种想法无法扩展到大型Magento商店，并且使Magento 2变得非常复杂，缓慢且难以使用。

EAV is impractical on a relational MySQL database not designed for EAV. This fact, however, doesn’t show itself until you’ve reached a certain (arguably low by today’s standards) scale.

对于不是为EAV设计的关系MySQL数据库，EAV是不切实际的。 但是，直到达到一定程度(按今天的标准来看可能较低)，这个事实才会显现出来。

EAV relation database structure was relegated to the museum of programming history, section ‘ideas that didn’t work out’ (the largest section in the museum). Any modern software doesn’t use this pattern.

EAV关系数据库的结构被归类为编程历史博物馆，即“未解决的想法”部分(博物馆中最大的部分)。 任何现代软件都不使用此模式。

Magento ORM中缺少的功能 (Features missing in the Magento ORM)

• Associations (has one, has many, belongs to, many to many, polymorphism, single-table inheritance)

  关联(具有一个，具有多个，属于，多对多，多态性，单表继承)

• Hooks (before/after create/save/update/delete/find)

  挂钩(创建/保存/更新/删除/查找之前/之后)

• Eager loading with Preload, Joins, Explicit Join + Eagerload

  预先加载，联接，显式联接+预先加载的预先加载

• Transactions, Nested Transactions, Save Point, RollbackTo to Saved Point

  事务，嵌套事务，保存点，回滚到保存点

• Row Level locking

  行级锁定

• Context, Prepared Statment Mode, DryRun Mode

  上下文，准备陈述模式，DryRun模式

• Batch Insert, FindInBatches, Find/Create with Map, CRUD with SQL Expr and Context Valuer

  批处理插入，FindInBatches，使用地图查找/创建，使用SQL Expr和上下文评估器的CRUD

• Composite Primary Key, Indexes, Constraints

  复合主键，索引，约束

• Auto Migrations

  自动迁移

• Data Seeding

  数据播种

• Versioning

  版本控制

• Database Resolver (multiple databases, read/write splitting) / Prometheus…

  数据库解析器(多个数据库，读/写拆分)/ Prometheus…

• API first

  API优先

• Distributive Catching Layer (Redis)

  分布式捕获层(Redis)

• Developer Friendly

  开发人员友好

Magento 2 ORM功能：(Magento 2 ORM features:)

• Basic CRUID Operations load(), save(), delete()

  基本CRUID操作load()，save()，delete()

现代SQL ORM解释 (Modern SQL ORM explained)

演示地址

翻译自: https://medium.com/@egorshytikov/magento-2-legacy-orm-explained-178431305fb9

magento企业版安装