cakephp開発回顧

ishii soft

目次

  1. はじめに
  2. コントローラ
  3. モデル
  4. ビュー
  5. ユニットテスト
  6. ツールなど
  7. 最後に

はじめに

以前、cakephpの勘所というスライドを作成しまして、
それを踏まえてシステム開発を行いました。
当資料では、その結果のふりかえりをまとめます

コントローラ

  • 共通処理をComponentsに作成したが、後にリファクタリングで/app/Vendorへ移動した。
  • →Controllerから呼ばれるかModelから呼ばれるかを意識しないといけないのは手間。
  • 例外処理はしなかったが、以下の方法で組み込み関数からも例外を発生させられるようであった。
  • PHPの組み込み関数で例外を発生させる方法
    →デフォルトで例外が発生しないということは、PHPでは例外処理を書かないのがスタンダード?
  • バリデーションはココから呼びたかったが、開発者の足並みが揃わなかった。
  • Controllerで呼んだり、Modelで呼んだり。。

モデル

  • アクション単位でクラスを作成していたら、クラス数が肥大化。
  • →bootstrap.phpのApp::buildにフォルダ指定すれば、フォルダ分けできるようだ。
    CakePHPでコントローラーとビューをディレクトリ分けする方法を教えてください。
  • テーブルアクセス処理はDAOクラスに分離するべき。
  • →ユニットテストで業務ロジックとテーブルアクセスを完全に切り分けられるので、テストがしやすくなったと思う。
  • テーブルアクセスは、簡潔に処理が書けてよかった。
  • 共通処理をビヘイビアに作成したが、デメリットのほうが多かった。
  • - メリット
    • Modelで使う共通処理だということが直感的に分かる

    - デメリット
    • Modelクラスを継承して作成しても問題ない(ModelからModelは呼べる)
    • ユニットテスト時に少し細工が必要
    • ビヘイビアのテストケース
    • ユニットテストでモックする方法が不明

ビュー

  • ヘルパーが<div>とか<label>とか余計なタグを作ってくれて迷惑。
  • →optionでfalseを指定して抑止。

ツールなど

  • リクエストやセッションが確認できるdebugkitは便利だった。
  • eclipseを使用したが、コードアシストやリファクタリングが非力で、あまり恩恵を受けなかった。PHPは型が曖昧なので、補完ができない。
  • ユニットテストでFixtureを使用したが、データ構造を思い出すのがしんどい。

最後に

  • CakePHPは癖の多いフレームワークだ。特にModelとテーブルの関係性が強すぎるのは扱いにくい。
  • 多機能のため、ルールを決めないとすぐにプログラムがぐちゃぐちゃになってしまう。
  • CakePHPに限らないが、MVCフレームワークでは、それぞれの役割できちんと処理を分離すること。あたり前のことだけれど、意外に出来ていないことが多い。
  • 習得が簡単なフレームワークと云われるが、インターネット上に情報は多く、問題解決がしやすいのは確か。
  • PHPは適当に書いたものがなんとなく動くのには抵抗があるが、フレームワークとしては悪くはなかった。

cakephp_memory

By nobuyuki

cakephp_memory

  • 1,111