モノノフ日記

普通の日記です

第2回設計勉強会に参加してきました

php event

第2回設計勉強会に参加してきました。

あんまりWebアプリケーションを構築するアーキテクチャ側の話がメインの勉強会に参加したことが無かったので新鮮に話が聞けました。普段、意識せずにフレームワークのルールに慣れすぎているとアーキテクチャ的には変だけどまぁいいか、的な使い方をしてしまいがちなので気をつけたいところです。
じっくり考えてみたいトピックでもあるので、発表資料公開をめちゃくちゃ期待してます！ ＞ 発表者の皆様

ust中継もされていて、後日動画も公開されると思うので興味ある方はぜひご覧ください。というか、Webアプリを触るエンジニアには一見の価値があるので見るべし。Lingrのアーカイブはになります。

懇親会ではアーキテクチャの話やDAO周りのお話やテストのお話、携帯サイト開発の不毛っぷりなど多岐に渡って歓談しました。

2008/11/10追記

動画が公開されました。NEKOGET++
ねこげっとぷれす » 11/5 第2回設計勉強会に参加してきました。

「クイズ研」開発上の設計判断とその結果 (発表資料)

  • twkさん
    • あたまソフトで活動されてる
クイズ研について
  • Zend Framework製
    • はじめてZFを利用
  • Googleで1位
    • Yahooだと10位くらい
  • iPhoneにも対応してる
  • 規模はまだ小規模
Zend Frameworkを選んだ理由
  • PHP5かきたかった
  • ライブラリライク
    • MVC気にしなくても良い
    • 使いたいところだけ使うスタイル
  • ジェネレータがあんまり好きじゃないから
    • Zend_Toolで導入されるらしい
  • 知り合いから好評だった
  • Zendが作ってるから廃れにくそう
クラス構成の概要
ポリシー
  • できるだけZFの標準で書く
  • require_onceはauto_loadに頼る
  • ifが１行なら{}は書かない
  • if: else: endif; の構文使ってる
  • ZFのチュートリアルではdispatchにコード直書き
    • 共通の基底クラスにした方が使い回しやすい＆安全
    • 共通処理＋ユーティリティ関数
DAO
  • Zend_Db_Table_Abstract
  • mysqli
  • getter, setterはテーブル単位で利用する方針
    • getAuthor, getUser とか
  • ViewからもModelアクセスはさせてる
  • new使わず、FactoryMethodパターンを使う
  • DAOかませば、その中でSQL直接書くのは構わないというポリシー
mysqli
  • 新しい目のMySQL使ってるからなんとなく
  • メリット
    • 特になし
  • バグあり(ZF-2659)
    • statementを使う場合、自前でcloseしないとダメ
テスト
  • テストコードは書いてない
    • 手動
  • 外部への影響もないので、コストを第一に考えた結果
Smarty
  • OOP的に書きづらい
  • 自動エスケープはON
  • 今は使ってない
    • Zend_View使ってみたかった

レイヤー切り分けてる？

  • ハタさん
発表資料

Event Php Study Design 2
View SlideShare presentation or Upload your own. (tags: php design)

はじめに
  • 意識しないと１つのクラスが巨大化していく
    • *Utilsとかいうlibファイルばっかりとか
  • phpでも気をつけるべし
レイヤーパターン
  • 処理機能、シナリオ単位に階層化するアーキテクチャ
  • 依存関係の方向性を一方向に
レイヤーごとの役割
プレゼン
  • 画面作る処理
サービスレイヤ
ドメインレイヤ
  • DBとのやりとり
MVCパターン
  • GUIのような対話システムのためのパターン
ここまでのまとめ
  • MVCという概念ではなく、もう少し小さな単位でレイヤを
  • シナリオ単位でのレイヤ
  • レイヤは規約
よくあるパターン
  • Teeda@Javaより
  • Full Pattern
    • PHPで扱うにはデカいよね
    • DXOが・・・
  • Middle Pattern
  • 結構いい感じだけど
    • DXOが・・・
  • LightWeight Pattern

ハタさんが使ったパターン

  • 基本3レイヤー
    • Action
    • DAO
    • Service
Service -> DAO
  • Propelだとrow table単位での処理になっちゃう
  • DAOはテーブルにINSERTしたり、SELECTしたりするだけの存在
概要
  • 各レイヤーは依存を作らないように複雑にしない
  • ほとんど new stdClass / array()
  • DTOをつくる
  • レイヤー間のオブジェクトはread only
  • ViewへはDTOを持っていくことも
  • なるべくインターフェースを用意
  • mockの実装とかを切り替えやすく = Testが楽になるように
メリット／デメリット
  • メリット
    • 画面処理 <<< 業務処理
    • レイヤー単位でのUnitテスト
    • 切り離しが容易なので、テスト単体でも動く
    • Serviceからの結果セットの変化も楽
  • デメリット
    • DBコネクション情報をFWが持ってると困る
    • 依存関係の解決は結構難しい
      • DB以外にもLogger
    • i18n / Context
Daoの部分
  • Hermit
    • CodeReposでつくってる
    • S2DAO.PHP5がデカいので小さめに
    • Tx/TxRuleの記述ができることがメイン
Q&A
  • レイヤー細かく切ると規模が大きくならない？
    • テストありきの設計なので、そこは目をつぶる
    • 他チームとの連携優先

結局Webのアーキテクチャーって？

  • kunitさん
  • レイヤーアーキテクチャとMVCは微妙にずれる
  • ActionはModelオブジェクトをViewに渡すので結局ViewからModelへのアクセスが発生してる
  • やっぱMVCは密結合になる
  • インターフェース重要
    • 各部分の依存性を低くする
  • チーム内でアーキテクトの人
  • フレームワークは100%のルールを与えてくれる訳じゃない
  • 60%くらいをFWが与えてくれる
    • その上に社内、チーム、プロジェクトのルールを乗っけていくべき

最後に会場を提供していただいた株式会社ディノさん、モデレータのid:shimookaさん、懇親会幹事のid:lindさん、ありがとうございましたー！