ORMは不快なアンチパターン | To Be Decided
このエントリでは、Yegor Bugayenkoによる記事、ORM Is an Offensive Anti-Patternを紹介する。 (Yegorから和訳と転載の許可は得た。) 以下はその全文の和訳だが、意訳超訳が混じっているので、もとのニュアンスを知りたければ元記事を読んでもいいし、読まなくてもいい。 結論から言えば、ORMはオブジェクト指向プログラミングの原則の全てに違反するひどいアンチパターンだ。オブジェクトをバラバラに引き裂き、もの言わぬ受身なデータ入れに変えてしまう。 小さいWebアプリケーションから、数千のテーブルをCRUD操作するエンタープライズシステムまで、どんなアプリケーションにもORMが存在することはゆるせない。 代わりになるものは? SQLを話すオブジェクトだ。 ORMの仕組み オブジェクト関係マッピング (Object-relatinal mapping、ORM
YappoLogs: Data::Model っていう ORM みたいの CPAN にあげたよ
Data::Model っていう ORM みたいの CPAN にあげたよ あざーす。循環参照しすぎるとバターになる。。なんでそんなに人の目を気にするのだろうと、マジレス。 早速ですが Data::Model っていう O/Rマッパー 的な物を CPAN にあげました。 Data::Model http://github.com/yappo/p5-Data-Model/tree/master 元来は MVC モデルで言う所の Model を一括でまかなえるつもりで実装していますが、ロジック処理は普通の Perl のクラスで書いちゃった方が潰しが聞くため、主にストレージを Perl のオブジェクトにマッピングする ORM 的な使い方が主流となっています。 そして、 Data::Model の多くの実装や設計などは Data::ObjectDriver を参考にして開発しました。 他にも後述して
ORMを作るために最低限必要な4+1のコンポーネント - Yappo::タワシ
短期間でCPANに上がってる名が通ったO/Rマッパ+αを目を通して、ORMマッパの必要最低限なコンポーネントを整理した。ぶっちゃけもっと削っても良いが一般的にするためにもリストアップ。 ORM 基幹的なクラスで使い方はORMによりけりで、特に無くても良い。 ORM::Schema テーブル定義を行う場所。物によってはデータベースの定義だけ行って。テーブルの定義はORM::Table的な物で行う。 どっちにしろテーブルの定義には変わらない。 大ざっぱに言うと、このクラスからselect系のメソッドが生えている。 ORM::Iterator 結果の行を取り扱うイテレータ。 DBICならDBIx::Class::CursorになりMoCoならDBIx::MoCo::Listが担当。 ORM::Row 結果の行ごとのオブジェクト。だいたいはORM::Schema or Table で定義してるco
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
