DCI (data context interaction)
DCI アーキテクチャという設計についての考え方がある。数年前から scala 界隈で盛り上がっていた記憶があるが、最近は ruby/rails 界隈でも盛り上がっている模様。 先日の札幌 ruby 会議で角谷氏が発表を行っている。 rubykaigi http://sapporo.rubykaigi.org/2012/ja/schedule/details/79.html スライド http://kakutani.com/20120916.html#p01 そこからたどって以下のような資料があるのも発見した。 objects on rails （書籍の無料公開) http://objectsonrails.com/ Clean Ruby http://clean-ruby.com/ 書籍サイト。ベータ版書籍が購入可能。$42なので電子書籍にしてはかなり高い。 DCIの講演 tog
model を物理レイヤーと論理レイヤーに分割する。
エンタープライズrailsという書籍に、モデルをphysical レイヤーと logical レイヤーに分けろ、というアドバイスがあった。この分け方が絶対かといわれるとよくわからないが、私も基本的にはこの考え方には賛成だ。 モデルのレイヤーを分けて考えるということはrailsのような密結合のフレームワークにおいて長期にわたってメンテナンスするコードを書くのであれば必須の事項になると思う。 どのようなレイヤーが必要になるかはアプリの複雑度によると思うが、最低限必須なレイヤーが上で書かれているphysical(DB層) とlogical(ビジネスロジック層) の二つのレイヤーだ。モデルのメソッドを physical と logical に分離し、controller から呼び出すのは基本的に logical 層のメソッドに限定する（厳密に守る必要はないと思うが）こととする。 例えばブログの記事
model の module 化
巨大な rails アプリを作っていると、すべての業務ロジックをモデルに書くというrails標準の考え方はすぐに破たんする。最もコアのモデルだと数千行を簡単に超えてしまうためである。長すぎるメソッドが良くないのと同様に、長すぎるクラスもよいものではない。 そこで module やラッパーを使って、特定の場面でのみ必要な機能を付加する、ということを考える。通常の rails の考え方では、モデルにはそのモデルに関係したビジネスロジックを書く、ということになっているが、そのモデルのビジネスロジックのうち、特定の場面でのみ必要なロジックを「場面ｘモデル」の単位でコードを切り出してmodule化しておき、必要なときにそれを include するということをしている。 例えば入力画面でのみ必要なメソッド、というのはよくあるはず。確認画面に表示するためのメソッドだったり、入力フォームを構築するために必
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
