任意の粒度で調整することの意義のメモ
http://d.hatena.ne.jp/noopable/20090126/1232929073
ここでの関連で、ちょっとメモ
http://el.jibun.atmarkit.co.jp/g1sys/2009/01/post-037e.html
その答えは、テーブル設計を最後に行うことです。これがデスマーチを防ぐには一番の近道なのです。
お客さんからの急な要望で固まっていたモデルに変更が加わることがある。
たとえば、文字列型で固定だったフィールドを、複数選択式にしたいとか。
そんな時、完全分離されたMVCレイヤーが一枚だと
- モデルの書き換え
- コントローラーでの判定の処理の書き換え
- ビューの書き換え
という3点をシステム全体というスコープ内に切り分けられたそれぞれの分類の中で調整する必要がある。
調整点が多ければ、テストケースも分散してミスの元になる。
逆に、完全自動な近頃のFWだと、YAMLの1行書き換えで済むよ？な話ではある。
しかし、カスタマイズ要件が多数存在していた場合、カスタマイズがデータ構造に依存していなければという条件付きなる。
何らかの変更のニーズを満たすとき、それに対応するコードはなるべく凝集、さらに言えば1か所の書き換えで済むように心掛けたい。
しかし、変更の粒度はエスパーなお客さん依存なので、予測して構成するのは困難。とすれば、任意の粒度で変更可能になるようなクラスター風なシステム構成にしておくのが無難かもしれない、というのがZend_Formを利用していくコンセプトかな。
変更の対象が凝集していれば、1レイヤーで分散されたコードを同時に変更するというロスも、自動化されたシステムでのカスタマイズポイントの把握も必要なく、適切な個所で適切な粒度での調整をする方がわかりやすいんじゃないか？と。
変更を凝集するには、MVCが変更の粒度に合わせて集まっていることが望ましい。
MVCの粒度を任意に調整した構成なら、変更の粒度に合わせて対象を絞ることで、その書き換えの影響を1スコープに集めることができるようになる。
フォームに対する変更ならZend_Form内のMVC、個別要素に対する要素ならZend_Form_Element内のMVCという具合に。
※実際はどの方式だろうが、下手打ってれば一緒だし、上手く実装するノウハウってのが存在するので優劣がつく話じゃないんだけど。
実際、これって、redhat-lsbがいいか、それとも/usr/local/に1パッケージ突っ込むのが好きかっていう好悪の問題に近いような気もする。
粒度を管理する上手い方法があれば、それを使えばいいっていうお話に落ち着くのかもしれない。
