Mage_Eav_Model_Entity_Setupたとえば、多くの子孫があります
class Mage_Checkout_Model_Resource_Setup extends Mage_Eav_Model_Entity_Setup
{
}
しかし、それらはすべて空です。
これらすべての空のクラスを持つことの用途は何ですか?
拡張性と、同じモジュールの異なるセットアップ スクリプトで共有される共通機能を維持するためだけですか?
これらのカスタム クラスによって何らかのモジュール自動検出がトリガーされるのではないかと考えていましたが、この方向へのヒントは見つかりませんでした)。
(Magento Certification Study Guide に基づく: カスタム モジュールで EAV 属性を操作するためにカスタム セットアップ クラスを使用する利点は何ですか)。
まず、Magento がコードをモジュールに編成していることを理解する必要があります。モジュールの背後にある考え方は、開発者が他のシステム コードに干渉しないような方法でコードを作成するのを支援し、強制することです。
次に、モジュールが Magento データベースに永続データを作成する必要がある場合は、セットアップ リソース(セルフリンク) を作成します。セットアップ リソースは、親クラスを介して特別な関数/メソッドにアクセスできるインストーラー スクリプトです。これらの特別な関数/メソッドは、開発者がデータベース内にデータ構造のテーブルを作成および設定するのに役立ちます。これらのメソッドの多くは、 Mage_Eav_Model_Entity_Setupクラスにあります。
開発者は、独自のモジュールのセットアップ リソースを作成するときに、新しいクラスを作成します。新しいクラスを作成することにより、セットアップ リソースが必要とする特別なメソッドが存在する場所が確保されます。Mage_Checkout_Model_Resource_Setupクラスは、モジュールのMage_Checkoutセットアップ リソース クラスです。このモジュールが追加のメソッドを必要としなかったのはたまたまです。Magento の以前のバージョンでは、モジュール開発者がセットアップ リソース機能を使用する場合、独自のセットアップ リソース クラスを作成する必要がありました(少なくとも、実際に作成したと思います)。これは、段落 1 で述べたように、Magento のモジュール システムが、モジュール A のコードがモジュール B に干渉しないようにするために存在するためです。
ロジックを理解するには、Alan Storm のチュートリアルを読む必要があります。正しい順序で読む必要があるかもしれませんが、このページに直接ジャンプすることもできます。彼らは間違いなく、数年前に何が起こっていたのかを理解するのに役立ちました.