第2回設計勉強会を聞いてきました
「第2回設計勉強会 - events.php.gr.jp」
会社から走ってなんとか始まる前に着けました。
「クイズ研」開発上の設計判断とその結果
twkさん
クイズ研というサービスを作ったときのはなし
ZFをつかって作ったそうです。
その後に請負で作ったものもある 新規だけでなく
レイヤ構成
コントローラー
DAO
テーブルアクセスクラス
MySQL
DAO
modelsフォルダの中
auto_loadを使う
面白いと思ったのは、Smartyのデリミタが
<?//{
}?>IDEでうまくいくかと思って試したが、不評だしうまくいかなかったので、その後使ってないそうですw
DAOでラップすればSQL書いてもいいのでは？
Smartyのメリット
短くかけることが多い htmlがきれいに見れる
自動エスケープはOn
それ以降ではSmarty未使用とのことw
Viewにロジックはあり？なし？
というのが疑問だとか。
Viewはテンプレートというわけではないので、ありだよという突っ込みが周りからありました。
レイヤー切り分けてる？
はたさん
レイヤー使ってる？
レイヤーパターン
依存関係が一方向
Webフレームワーク→サービスレイヤ→Dao
レイヤーごとの役割
入出料組み替え ビューの構築
画面ロジックの構築 サービス例やへの引き継ぐ値の構築
サービスレイヤ
ドメインロジックを構築
トランザクション
ビジネスロジックのためのインターフェース
ドメインレイヤ
データベースとのコミュニケーション
いろいろあるので大丈夫
WebアプリケーションにおけるMVCは一レイヤ
シナリオ単位でレイヤをきっている
レイヤは規約
レイヤを超えてアクセスしない
DXO
レイヤ間の依存をなくすための
Data eXchange Object
画面ロジック ドメインロジックの２パターン
業務ロジックはロジック
画面とDBが１対１
ほぼプレゼンテーションロジックに向いてる
基本３つのレイヤー
Action Dao Service
各レイヤーは依存を作らない
DTOは作る
readOnlyのオブジェクトを返す
ViewにはDTOを持っていくこともある
Mockの実装とかを楽になるように
インターフェースを書くようにする
レイヤー単位のUnitテストがかけるので楽
見通しがつきやすい
Serviceレイヤーより後ろはFWと切り離しができる＝依存が少なくなる＝テストしやすい
DB Loggerなどの依存関係の解決が難しい
S2Daoが自分で使うには大きすぎて使えないとのことですw
新しいものを作っているそうなので期待。
レイヤー分けをしてどのようになるのかがわかりにくかった
依存を減らして、テストが楽になるというのは興味がある。
ロジックのclassをシンプルにし、テストをしやすいようにというのは参考になりました。
レイヤ指向？というのは始めて知った。
結局Webのアーキテクチャーって？
id:kunit さん
レイヤーとMVCは違う 合わない
MVCは密結合になる
コミュニティに還元すべき
実際に動くコードで見比べたり、それをもとに話す必要がある。
そのためのひな形としてPhwittrとか。
弊社サービスの場合の設計
id:shimooka さん
モビログというサービスについてのデモ。
実際にうちの会社で使っているのだが、モバイル用としてはとても高機能でいい。
で、それのリニューアルで実際に書いているコードやテストを実際に見せてもらう。
PHPUnitを使っているとのことでした、
その中ですばらしいと思ったのは、コードのテストカバレッジ率が出るのと、実際にコードのどこをカバーしているか、逆にテストできていないかをビジュアルで見ることができていました。これはすばらしい。
PHPUnit3の機能らしいので、ぜひ使ってみたい。
http://www.phpunit.de/pocket_guide/3.0/ja/code-coverage-analysis.html
懇親会
なんか熱くいろいろ話していました。
会場提供してくださった、ディノの噂のビールサーバを使えましたしね！
最後に
id:shimookaさん、第一回に続き第二回の設計勉強会の主催おつかれさまでした。
会場提供してくださった、ディノさんありがとうございます。
懇親会の幹事をしてくださった、LINDさんありがとうございます。
いま、一番興味のあるテストやフレームワークの思想とかそのあたりで、いろいろ刺激を受けました。
