読者です 読者をやめる 読者になる 読者になる

第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
レイヤーごとの役割


入出料組み替え ビューの構築
画面ロジックの構築 サービス例やへの引き継ぐ値の構築


サービスレイヤ
 ドメインロジックを構築
 トランザクション
 ビジネスロジックのためのインターフェース

ドメインレイヤ
 データベースとのコミュニケーション
 いろいろあるので大丈夫


MVCアーキテクチャパターン

WebアプリケーションにおけるMVCは一レイヤ

シナリオ単位でレイヤをきっている
レイヤは規約
レイヤを超えてアクセスしない


DXO
レイヤ間の依存をなくすための
Data eXchange Object



画面ロジック ドメインロジックの2パターン
業務ロジックはロジック


画面とDBが1対1
ほぼプレゼンテーションロジックに向いてる


基本3つのレイヤー
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さんありがとうございます。


いま、一番興味のあるテストやフレームワークの思想とかそのあたりで、いろいろ刺激を受けました。