2009 March | sylvan - ソフトウェアづくり日記

Archive for March, 2009

symfony1.1以降で開発する際に必ず守ること箇条書き

Saturday, March 21st, 2009

schema.yml
- カラム名には id、created_at、updated_at、created_by、updated_by を利用する
- join して利用するテーブルには外部制約を必ず設定、テーブル名_id を利用する
- database.yml、propel.ini の設定は symfony configure:database コマンドを使う
命名規則
- 変数、関数名は camelCase で
- app.yml の変数名は snake_case で
- コメントなしでもわかるような名前をつけて、わかりきったコメントは書かない
コーディングルール
- type hinting を使う
- if、for、foreach、switch 文の括弧は symfony 形式で
- 比較文に ==、!= は絶対に使わない。===、!== を利用する。でも is_null とかはもっと使え
- 文字列を連結する時はピリオドと文字列の間に半角スペース。（例）
  
  $text = 'text1' . 'text2' . 'text3'
- php の定数は小文字で。（例）null、true、false など
- コード内のコメントなどに全角スペースを使わない
- 関数の return 値に空文字を使うなら null を使え
全体
- SQL 文を直接書かない、頑張って criteria で書く
- 共通処理は親クラスを作成し、継承して利用する
- クラスのプロパティは絶対に protected or private で
- symfony の lib ディレクトリ以下を理解するとかなりレベルアップ
サーバ
- utf-8 で統一
アクション
- アクションにビジネスロジックを書かない
- アクションに criteria を書かない
モデル
- lib/model/om、map、lib/form/base の下はさわらない
- DB まわりのビジネスロジックは lib/model/xxxPeer.php に書く
- レコード単位の処理は lib/model/xxx.php に書く
- doSelectRS() で取得したレコードセットは populateObjects() を使ってオブジェクトに変換すると楽
- doSelectRs() で取得したレコードセットが 2 箇所以上から利用される場合は、レコードセットに合わせたモデルを作成し利用する
- DB の定数は xxxPeer.php に宣言
- 複数のモデルに共通の処理を挿入する場合は、sfPropelBehavior を利用する
フォーム
- Form クラスを必ず使う
- Form まわりのビジネスロジックは lib/form/xxx に書く
- 親子関係のテーブルを Form で利用する時は embedForm を使う
- input タグの name は xxx[xxx] の形式で書く。bind する時のロジックが短くなる。$this->widgetSchema->setNameFormat('xxx[%s]') を使う
- sfUser を使いたい時は、sfContext::getInstance()->getUser() を利用する
バリデーター
- 複数フィールドのバリデートには setPreValidator()、setPostValidator() を使う
テンプレート
- テンプレートには if、for などの簡単な条件分岐以外で php を利用しない
- layout 内で動的に切り替わる要素を使いたい場合は slot を利用する
- form を利用している時はテンプレートに関するロジックは form で、form を利用しない時は、viewXxx.class.php を作成しコンストラクタでオブジェクトを渡してロジックは view クラス内に閉じ込める
routing.yml
- get パラメーターのチェックは routing.yml で
エラー
- 400、500、unavailable.php の 3 つが設定対象
保留
- （ある程度規模が大きくなると、lib/service/serviceXxx.class.php みたいな symfony にできるだけ依存しないビジネスロジッククラスを作る案もありかも）
ヘッダーコメント