2つの ”Entity” ある種の ORM では RDB のテーブルスキーマモデルとなるクラスのことをEntityと呼んでいます。例えば PHP のDoctrineや TypeScript のTypeORMなどがそうです。 そういった ORM を採用したプロジェクトで DDD に取り組むとき困るのが用語の衝突です。ORM の Entity は RDB のための定義を含むため当然 DDD の Entity とは異なるのですが、なにぶん同じ名前なので混同してしまいがちです。 本記事では両者を混同せず扱うための考え方をまとめます。 Entity の定義 まずは定義から確認します。 DDD での定義 エヴァンス本の日本語訳から引用します。 主として同一性によって定義されるオブジェクトはエンティティと呼ばれる Eric Evans. エリック・エヴァンスのドメイン駆動設計 (Japanese Edi
Metastorage is an application that automatically generates code for an Object Oriented API to store, retrieve and manipulate the persistent objects of classes described in a high level data model definition. Metastorage provides a much more efficient development process for medium or large size applications that store and retrieve data from SQL based databases or other types of storage persistence
2016年12月22日にTransactd PHP ORMをリリースしました。 これはTransactdを使用したMySQL/MariaDB用のORMライブラリです。 今回はこのTransactd PHP ORMを紹介します。 Contents 主な特徴 高速なDBアクセス 省メモリ 高スループット 高可用性 自在なトランザクションとロック、スナップショット 詳細なドキュメント 欠点 詳細 ORMインターフェース リレーションのロードタイミング インピーダンスミスマッチ モデルのキャッシュ IDEのコード補完支援 プロパティアクセス速度 複雑なデータベース処理 まとめ 主な特徴 高速なDBアクセス Transactd PHP ORMは、ORMでありながらPDOを直接使用したアクセスよりも高速なデータアクセスができます。 下図は、TransactdとPDO、Laravel EloquentO
この場合、生徒テーブルの部活idをたどればどの部活に所属しているかわかる訳ですね。 生徒は一つの部活に入っていて、部活には多数の生徒が入っている。という関係になるので多対一という関係になります。なんか逆っぽいよねぇ。 多対1リレーションの限界 上の例では生徒は一つの部活にしか参加できない、また必ず一つの部活に入らなければいけなくなっています。 それでは部活を掛け持ちしている生徒や、何の部活にも入っていない生徒がいる場合はどうすればいいでしょうか? 生徒テーブルに部活idカラムを増やす? もし100種もの部活を掛け持ちしている超高校生がいたらどうでしょうか。それだけの部活IDを格納できるようにカラムを増やすのは現実的ではありません。 逆に何の部活にも参加していない生徒はどうでしょうか? 部活テーブルに帰宅部を増やす? いいえ、そのような部活は存在しません。部活というものを扱う部活テーブルに、
class Model_Atable extends \Orm\Model { : protected static $_has_many = array( 'bTable' => array( 'model_to' => 'bTable' , 'key_from' => 'APKey' , 'key_to' => 'APKey' , 'cascade_save' => false , 'cascade_delete' => false , 'conditions' => array( 'where' => array(array('field1','=','momo')) , 'order_by' => array('BPKey' => 'asc') ) ) );
まえがき この記事は, マーティンファウラーのエンタープライズアプリケーションアーキテクチャパターン(以下PoEAA本)の 12.7章「シングルテーブル継承」ほかの内容を元に書いております. 内容に間違いあるいは勘違い等がありましたら, ご指摘おねがいします サンプルコードについての注釈 この記事に含まれているサンプルコードでは, 特にが断りがない限り, 以下のようなモデルクラスを使用している <?php /** * 全てのカードの基盤となる抽象クラス * */ abstract class Card { public $id; public $name; } /** * 種別=アイドルのカードを表すモデル * */ class Idol extends Card { public $cost; } /** * 種別=トレーナーのカードを表すモデル * */ class Trainer e
fuelphpのORMが提供するメソッドを利用していてハマりました。 はまった内容としては ORMのfindメソッドを利用して指定したidが一致するレコードを取得する際、検索結果をfuelがキャッシュし、次回以降同じidのレコード検索を行った時、SQLクエリが実行されず、キャッシュしたデータが返されるということ。 このせいでユニットテストが思うように動作してくれず、どハマりしました。 結論 fuelphpのORMにはデータのキャッシュ機能があるようで、テスト実行によるデータのキャッシュ履歴が、次のテストケースに影響を与えてしまっていました。 動作確認(ORMメソッド利用) 例えば次の処理を実行させます。 $user = Model_Users::find(1); $user->name = 'name'; $user->save(); $user = Model_Users::find(1
最近がっつりハマってしまったfuelphpのORMモデルメソッド利用時の仕様について。 ORMのCRUDメソッドを利用してDBアクセスした場合、fuelのフレームワークがよかれと思ってアクセス時のデータをキャッシュしてくれます。 そして同じレコードに対するデータアクセスがあった場合には、そのキャッシュデータを返すという仕様になっているようです。 この仕様のせいでどえらいハマってしまったので、記録として残しておきます。 ORMのCRUDメソッド実行時の詳細なSQLクエリ実行の様子や、キャッシュを避けるための方法についてはQiitaにまとめて投稿しておりますので、そちらをご覧ください。 qiita.com 今回得た教訓としては、 ・データの設定や実装が正しいのに、想定する結果とならない時はデータキャッシュを疑え ・フレームワークを信用しすぎない ということ。 この二つは連動しており、フレームワ
<?php trait OrmFindMethods { public static function find_by($conditions) { $options = static::build_options($conditions); return static::find('first', $options); } public static function find_all($conditions = [], $limit = null, $offset = null) { $options = static::build_options($conditions, $limit, $offset); return static::find('all', $options); } protected static function build_options($conditio
現在使用しているテーブルに新しくカラムを追加したのですが、 何故かコントローラからモデルオブジェクトを呼び出してカラムを使おうと思っても上手くいかなかったので、 同じ事象に遭遇した人の為に記事を書きました。 この問題はモデルのprotected static $_propertiesがカラム追加をしても更新されない為に起こる問題でした。 protected static $_propertiesはコマンドラインでモデルを作成すると自動的に作られます。 下記のように新規に追加したカラムをprotected static $_propertiesに追加することで解決しました。 例 protected static $_properties = array( 'id', 'カラム名', 'created_at', 'updated_at' ); ↓ protected static $_prop
このエントリでは、Yegor Bugayenkoによる記事、ORM Is an Offensive Anti-Patternを紹介する。 (Yegorから和訳と転載の許可は得た。) 以下はその全文の和訳だが、意訳超訳が混じっているので、もとのニュアンスを知りたければ元記事を読んでもいいし、読まなくてもいい。 結論から言えば、ORMはオブジェクト指向プログラミングの原則の全てに違反するひどいアンチパターンだ。オブジェクトをバラバラに引き裂き、もの言わぬ受身なデータ入れに変えてしまう。 小さいWebアプリケーションから、数千のテーブルをCRUD操作するエンタープライズシステムまで、どんなアプリケーションにもORMが存在することはゆるせない。 代わりになるものは? SQLを話すオブジェクトだ。 ORMの仕組み オブジェクト関係マッピング (Object-relatinal mapping、ORM
class Model_Base extends \Orm\Model { public static function insert_multi($datum) { $table = static::table(); $columns = array_keys(static::properties()); $query = \DB::insert($table) ->columns($columns); foreach ($datum as $data) { $values = []; ($data instanceof \Orm\Model) and ($data = $data->to_array()); foreach ($columns as $col) { $values[] = (isset($data[$col])) ? $data[$col] : null; } $que
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く