LoginSignup
0
0

More than 5 years have passed since last update.

設定系のKVSなのでActiveRecordパターンなORMでいいんじゃね って思った。

Last updated at Posted at 2016-05-17

概要

社内で書いた日報の転記です。
正直、読みにくいポエムだとは思いますし、ブログに書けよwwwって感じもするのですが、ブログとかやってないので、ここにメモっとく感じで置いときます。

以下、転記。

表題の通りであり、そのままなのだが。「設定系のKVSなのでActiveRecordなORMでいいんじゃね」って思った。
設定は、以下の様に、Key-Value のペアで表現される。

  • Primary Keyが単純な1カラムだけだろうが、複合主キーになっていようが、それはKeyであることに変わりはない。
  • 設定内容は、Valueである。
  • それに追加で、create_at とか update_at があるかないか、という些細なフレーバーがあるかもしれない。

設定を保存しておくリポジトリなんて、この程度だ

で、KVSリポジトリなら、ActiveRecordパターンでいい。

各PHPのフレームワークでのActiveRecordパターン(的なもの)の実装

ところで、ActiveRecordパターンは「"Modelの作成"を如何にして実装するか」というそもそもの問題がある。
大抵の場合、フレームワークレベルで対応している。

ActiveRecordパターンってなんぞ

これについては、「ActiveRecordパターンの要件」を以下のようにすげ替えて、問題を解消した。
個人的には、以下の要件を満たしていれば、ActiveRecordだと思うことにした。

  • MVCのModel (Clean Architecture なら、ドメインレイヤのRepository) として使えるだけの実装がある
  • saveメソッドをインターフェースとして持っている。
  • 1インスタンスがリポジトリの1レコード(DBならテーブルの1行、Redisなら1KV)に相当する

上記の3つの使用は、クラスの3つの役割 について言及した形となっている。
実用する場合は、どうせオブジェクト指向にするので、"ActiveRecord抽象クラスを継承する" or "ActiveRecordインターフェースを実装する"になるだろう。(メッセージ指向、クラス指向の両方の意味で、"オブジェクト指向"と言っている。)
なので、実装する上での指針を示す形で、要件を定義した。

この要件にすげ替えた言い訳

多分だけど、WikipediaのActiveRecordを見ている限りだと、これで「ActiveRecordパターン」って言い張っても大丈夫なのかなぁと思ったりした。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0