ここ最近EC-CUBEに触れる機会が多く、新規機能の開発や不具合対応などの保守作業を
行っております。
しかしEC-CUBEの基礎をちゃんと理解しないまま作業している節がありましたので、
今回は自分への学びの機会の一貫としてEntityについての記事を残します。
Entityとは？
Entity(エンティティ)とは、原則 1 Entity = 1 テーブルの行と対応するPHPクラスのことです。
EC-CUBEはSymfonyとDoctrine ORMを使っているため、EntityはDoctrineの仕組みに沿って動作します。
仕組みと基本要素
| 構成要素 | 内容 |
|---|---|
| @ORM\Entity | このクラスがEntityであることを宣言 |
| @ORM\Table | 対応するデータベーステーブル名を指定 |
| @ORM\Column | 対応するカラム名、データ型、長さなどを指定 |
| @ORM\Id | 主キー（Primary Key）を指定 |
| @ORM\OneToMany など | 他のEntityとのリレーション（1対多、1対1、多対多など）を定義 |
| getXxx(), setXxx() | プロパティの値を取得・設定するgetter/setter |
Entityクラスのアノテーション(注釈)には、上記の構成要素で、このテーブルに対応していて、このカラムと対応しているという情報が記述されています。
Entityの裏では何が起っている？
- データベースのテーブル構造とEntity構造をマッピング
- Entityを通じてデータを扱うと、自動的にSQLを生成してデータベースとやり取りを行う
- 記述を行えばリレーションも追跡、取得してくれる
- persist() → flush() で変更を検出してINSERT/UPDATEを実行
Entityを使うメリット
-
コードが読みやすく、意図が明確になる
SQLをベタ書きせずに、$product->getName() $product->setName(XXX)のように直感的なコードでデータを扱うことができる -
再利用性と保守性が高い
一度定義すれば、フォームの作成、バリデーション、テンプレート、データベース保存などで再利用可能、特にフォームの作成においてはEntity を参照し、フォーム項目とのマッピングを行うことで表示・編集・保存を全て自動で処理が可能です -
リレーションをオブジェクトでたどれる
$order->getCustomer()->getEmail();
上記のように、注文→会員→会員のメールアドレスのようなたどり方が可能で
SQLのJOINを手動で書かずとも、Entity同士の関連付けをたどるだけでデータを参照できます。 -
SQLの重複・ミスが減る
SELECTやJOINを自前で書く必要が減るためSQLの重複が減る
また、フィールド名とテーブル名をEntityに記述しているので記述ミスが起きにくい
EntityとRepositoryの関係とは？
- Entityは上記でもご説明しましたが、あくまでデータベースの値の保持、構造の定義が役割であり、データの取得・検索・DBへの保存、削除は別のクラスである Repositoryクラス が担当します。
役割の違い
| 役割 | Entity | Repository |
|---|---|---|
| 概要 | データベース1行を表すオブジェクト | Entityに対応するデータ操作の担当 |
| 担当範囲 | 値の保持・構造の定義 | データの取得・検索・保存・削除 |
| 使用される場所 | Twig, FormType, 保存処理など | Controller, Service などのDB操作部分 |
| 操作の主体 | getXxx(), setXxx() | find(), findBy(), save()等 |
Laravelなどのフレームワークではデータベースの操作を Modelクラス が全て行うようになっていますが、EC-CUBEではEntityとRepositoryで分けて実装する形になります。
まとめ
私はLaravelを学習した後にEC-CUBEに触れることになりましたので初めはEntityとRepositoryの違いってなに？データをどうやって取得するの？と迷うことが多かったですが、LaravelのModel ≒ EC-CUBEのEntity＋Repositoryと認識してからは理解度が増した感じがしました。
さらにDoctrineの力で、フォームとの連携や保存・リレーションの取得まで自動化されていることを理解すると、Entityは単なる「クラス」ではなく、EC-CUBEの開発の中核だと実感できます。