* 22:33
PofEAA におけるドメインに対する3つのアプローチ[pofeaa]:
- トランザクションスクリプト
- ドメインモデル
- テーブルモジュール
今は、トランザクションスクリプトにプレゼンテーションがごっちゃになっ
たような状態。というか、FrontController にドメインロジックがつっこ
まれてる感じか。CDBI は ActiveRecord パターンなハズなんだけど、う
ちはいまビジネスロジックをほとんど Controller に書いちゃってるから、
テストしづらい。
Sledge Application は Controller を動かすと、CORE::print 呼んでし
まうので、色々と姑息なテクニックを駆使しないとテストコード書けず、
HTTP Server 経由で書いた方がむしろはやいような感じになっちゃうので、
ちょっと困り気味。
* 22:30
PofEAA における3つの基本レイヤー[pofeaa]:
:プレゼンテーション:ユーザとのやりとり
:ドメイン:ビジネスロジック
:データソース:データの場所
んー。
* 22:29
DataMapperとActiveRecord[pofeaa]:
プレインなオブジェクトがあればDataMapper。何かを継承していれば
ActiveRecord。
http://capsctrl.que.jp/kdmsnr/diary/20050522.html#p01
ふむー。わかったような、わからないような。
* 18:31
TransactionScripts[pofeaa]:
はてさて。今んとこ、TransactionScripts と InputController がいっしょ
くたになってて testability 最悪なんだけど、ActiveRecord を
DomainModel な感じにしたら、よくなるのかしら？
* 18:18
パターンは新しいものじゃない[bliki]:
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?PatternsAreNothingNew
「パターン本はパターンに名前をつけてそれを普及させる」ところに意義
がある。
* 18:16
技術的負債[design][bliki]:
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?TechnicalDebt
読んだ。最近とくにこのへんは意識しているのねん。
* 18:10
Presentation と Domain の分離[bliki]:
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?PresentationDomainSeparation
読んだ。たしかに、と納得。
今は Controller にドメインロジック書く方式でやってるんですが、テス
タビリティ最悪で泣ける。
ところで、ドメインロジック(ビジネスロジック)って用語はわかりにくい
気がするんだよなー。
* 16:35
PofEAA 読んだ![pofeaa]:
遅ればせながら読んだよ!arton さんの記事読んでよみたくなったあるよ。
* 16:04
DataMapper[pofeaa]:
http://capsctrl.que.jp/kdmsnr/wiki/PofEAA/?DataMapper
メモリ内のオブジェクトをデータベースから分離するためのソフトウェ
アレイヤ
なるほど。
* 09:58
HDDはつねにいっぱい[essay]:
なのといっしょで、読む時間が短くなるたびに読むフィードの数が増える
から結局かかる時間がかからないのよね。
