【PHP】フレームワークについて語るスレ【総合】

【PHP】フレームワー� ..

749:nobodyさん
05/12/07 23:23:39
zend frameworkｷﾀ━━(ﾟ∀ﾟ)━━━!!!
hURLﾘﾝｸ(www.phparch.com)

750:nobodyさん
05/12/07 23:50:26
>>749
英語のプレゼンだからサッパリわからんが
PHPをﾋﾟｨﾁﾋﾟｰと発音することは分かった

751:nobodyさん
05/12/07 23:53:53
ははは
もれもそれ思ったよ！これからﾋﾟｨﾁﾋﾟｰって言おう！

752:nobodyさん
05/12/08 06:40:50
>749
これっていつごろできるの？

753:nobodyさん
05/12/08 08:49:04
けっこうagaviに似てる気がする

754:nobodyさん
05/12/08 18:17:58 v7tgLnK2
>>741
じゃあdispatchからのforwardってなんなの？

755:nobodyさん
05/12/08 18:25:17
>>754
「転送する」とか「回送する」とかの意味があるから、「処理をまわす」と
いう意味合いじゃないの？

つか、ここは英語のスレじゃないんだが。

756:nobodyさん
05/12/08 22:50:03
Zendフレームワークっていつリリースか明記してある？

757:nobodyさん
05/12/08 23:13:00
±1.5ヶ月でね

758:nobodyさん
05/12/09 12:10:21
>>749
プレゼンが下手糞で途中で飽きた。

文章でまとまってるのないの？

759:nobodyさん
05/12/09 12:21:49
流行りだからって何でもかんでもPodcastすればいいってもんでもないよね｡
テキストなら大事なとこだけ拾い読みできるのに｡

760:nobodyさん
05/12/09 12:43:07
メディアを云々する前にまずGoogleを覚えようぜ

761:nobodyさん
05/12/09 14:16:53
誤爆ですか？

762:nobodyさん
05/12/09 17:59:40 kJFA21a1
Decorator使ってる時にリダイレクトしたら、
サブテンプレート作成中に処理がブチギレるよね。
ポストフィルタでリダイレクトすべきなのか。
そのあたりどうしてる？

763:nobodyさん
05/12/10 14:39:54
質問です。

mojavi2でSmartyを使っています。
XOOPSのテーマを使っていてsmartyのデリミタが<{と}>です。
$lblocks = array(array('title' => 'エラー',
'content' => '<div><{$error}></div>'));
$renderer->setAttribute('xoops_lblocks',$lblocks);

すると<がサニタイズされて>に変換されて、html上表示されてしまいます。
サニタイズさせない方法ってあるでしょうか?

764:nobodyさん
05/12/10 19:34:26
>>763
$smarty->left_delimiter = '<{';
$smarty->right_delimiter = '}>';

てか、、マニュアル嫁

765:nobodyさん
05/12/10 23:53:59
>>764
>>763の
>XOOPSのテーマを使っていてsmartyのデリミタが<{と}>です。
とあるように、その設定はXOOPSのテーマを使うために既にしています。
そのために<と>がサニタイズされて困っているんです。

その設定をしなければ、{と}だけで問題ないのです。
テーマ側に<{$error}>と書けば問題ないのですが、setAttributeで渡そうとすると
サニタイズされてしまいます。

766:764
05/12/11 01:36:43
>>763
>smartyのデリミタが<{と}>です。
これ読めてなかった…　すまん、763

767:762
05/12/11 11:51:35
リダイレクト後にexitしてるのが問題だっただけだった。
リダイレクトっていっても
ヘッダに出力するだけで、
処理が止まるわけじゃないんだよな。

768:nobodyさん
05/12/12 19:50:27
mojavi3つかってます。

modelで$this->getContext()->getRequest();するのと、
actionで$this->getContext()->getRequest();してモデルに渡すのと
どっちがmvc的に正しいですか？

769:nobodyさん
05/12/12 20:44:06
>>768
モデルはコントローラやビューと結合していないのが理想なので、action で
リクエストを取得して、それに応じて model に渡すのがよいと思う。

770:nobodyさん
05/12/12 20:44:31
「結合してない」って言い方は悪いな。「疎結合」に言い替える。

771:nobodyさん
05/12/12 20:44:42
>>768
前者の方がmodelとactionの結合が疎になりやすい。

772:768
05/12/12 21:33:07
どうもありがとうございました。

さっぱりしました。

773:nobodyさん
05/12/12 23:43:46
>>769
えええええええええええ？
だったらなんでmodelに
$this->getContext()->getRequest();
できる機能わざわざつけてあるのさ。

actionもMVCのmodelに相当するんじゃないの？
model内で
$this->getContext()->getRequest();とかやって、
actionでgetModelするのが普通だと思うが。

>>772よ。すっきりするのはまだ早い

774:nobodyさん
05/12/12 23:50:24
moja3て、Modelがあんだ～
class HogeModel extends Model って感じ？

775:nobodyさん
05/12/13 00:06:36
>>773
> actionもMVCのmodelに相当するんじゃないの？
違うよ。controllerとmodelのアダプタ（アダプタパターンとは別の意味）。
controllerの一部をコマンドパターンとして抽出したとも見れる。
だから本当はactionはビジネスロジックを書くところじゃないんだけど、ロジックもそのまま書けてしまう手軽さは利点であり欠点でもあると思う。
requestをいじるのはcontrollerであるべきだと思うから俺はaction内でgetRequestして、相応のmodelを呼び出す派。

776:768
05/12/13 01:51:59
やっぱり、model内で
$this->getContext()->getRequest();
のはなんか気持ち悪い。

777:nobodyさん
05/12/13 01:56:13
俺もactionでrequest派。
最初はmodelでやっていたが
そうなると、起点となるactionを見ただけでは
どんなパラメータをいじっているのかが分からず、
流れを把握しにくくなったから。
またリクエストパラメータはどちらかといえば
プレゼンテーション層に属するものなので
プレゼンテーション層であるactionで受け取るのが理にかなっている
とも思う。
バリデーションやコンバートはactionでやってるんだから
ノータッチでmodelに渡していても疎結合とは言えないのでは？
むしろactionで受け取ってmodelに渡すというレイヤパターンにした
方が疎結合といえる気がする。

778:nobodyさん
05/12/13 10:18:09
model で request 処理すると，model の unit test がやり辛くなると思う
それって context と request の両方を外部に依存することになるし

action で request を処理しちゃえば model は request の「値」のみに依存することになり
より疎結合になる

# なんてことを周囲に喋ると「日本語喋れ」とか言われる罠ｗ

779:nobodyさん
05/12/13 11:29:59
記述が楽＝疎結合じゃないんだよね
プロトコルを増やすわけだからむしろ記述は面倒くさくなりがち

780:nobodyさん
05/12/13 14:13:53
>>773
フレームワークが許容しているのと、理想的な設計との間には
隔たりがあるってことを理解するべき。

元の質問は
> どっちがmvc的に正しいですか？
‥なので、MVC 的には action に依存しない方が理想だろうね。

>>778 のいう「unit test がやり辛い」ってのは、model がフレームワークと
密接に結合していて使い勝手が悪い証拠。結合度が高いので、再利用しずらい
(再利用する時に、間接的にフレームワークにも依存することになる)。

model と action を分離しておけば、例えば、Web アプリとは別に DB に対する
バッチ処理を PHP で書く必要がでてきた時に model を流用できる。

ただ、理想的な設計が、即座に現場で適用されるべきかというと、それは
また別問題だけどな。

781:nobodyさん
05/12/13 18:51:28
>>780
いや、疎結合とかはlib側で考えるもんなんじゃないの？
＞フレームワークが許容しているのと、理想的な設計との間には
＞隔たりがあるってことを理解するべき。
許容じゃなくて、意図的に実装してるんだとおもうんだけど。
modelは明らかにactionと密接な連携を取るためのものだと思うし。

＞model と action を分離しておけば、例えば、Web アプリとは別に DB に対する
＞バッチ処理を PHP で書く必要がでてきた時に model を流用できる。
その流用はlibでつくったもののがやりやすいよね。

782:nobodyさん
05/12/13 18:54:29
>>777
自分は逆にactionはどんなmodelを使ってるかの道しるべとして使ってるから
流れ把握は全然困らない。てかむしろしやすい。

783:nobodyさん
05/12/13 18:59:51
てか、そもそもlibの存在忘れて疎結合とか言ってない？

784:nobodyさん
05/12/13 19:08:07
libって何さ、ライブラリ？

785:nobodyさん
05/12/13 19:10:01
なにこの流れ。
スゴいお勉強になるんだけお。

786:nobodyさん
05/12/13 19:11:38
>>780の言う「許容」ってのはModel内で$this->getContext()->getRequest()できちゃうって話だよね？
>>781と微妙に噛み合ってないみたいだけど。
つーかMojaviに関して言えばContextに一貫性を持たせようとした結果、たまたまModelの中でもRequestが取得できてしまうとも見れると思う。
その意味ではMojaviの欠点の一つかもしれんな。
まあ>>773から反論がない限りはgetRequestはActionでやるべきってのは満場一致でしょ。
その結論に至る思考プロセスが個々人いろいろなのがおもしろいなｗ

787:nobodyさん
05/12/13 19:18:52
>>786
ん？かみ合ってないのか？
＞つーかMojaviに関して言えばContextに一貫性を持たせようとした結果、たまたまModelの中でもRequestが取得できてしまうとも見れると思う。
つまり、Requestだけはmodelでやるべきではないってこと？getControllerやgetUserはありで？
だったらかみ合ってないてのはわかるんだけど。

>>784
いや、libはautoloadで定義するやつよ。
こいつにこそ疎結合を求めるもんだとおもうんだけど…

788:nobodyさん
05/12/13 19:21:40
>>786
ちなみにlibとmodelはどう区切ってる？

789:nobodyさん
05/12/13 19:34:56
M2のactionChainがなくなったのも、デコレータだけじゃなくgetModelが
追加されたからなんだと思うし…

790:786
05/12/13 19:40:45
>>787
いや、「かみ合ってない」って言葉が気に障ったなら気にしないでくれ。
疎結合の話に対してではなく、request云々の方で感じたこと。
> 許容じゃなくて、意図的に実装してるんだとおもうんだけど。
の部分ね。

modelとlibのどちらに疎結合を求めるかってのにはノーコメント。
俺の場合はlibにフレームワークのコンポーネントから外れた自分クラスとかは入れないんで。
多くはModelで、あとはSmartyの実装が微妙だったころに改造したViewとか。（最新バージョンがどうなってるのかはチェックしてない）。

> つまり、Requestだけはmodelでやるべきではないってこと？getControllerやgetUserはありで？
まあそういう風に見るとrequestとuserの非対称性が浮き彫りになるが、俺の場合は結果的にはそういう方針でやってるよ。
Modelの中でgetRequestを呼び出すのはせいぜいsetErrorするときだけだな。

>>788
前述の通り、俺的には「区切ってる」っていう感覚ではあまりない。
共通して使うものをlibに入れるだけ。

791:nobodyさん
05/12/13 19:51:24
フレームワークだから
ある程度の自由度を残してるのは当然ともいえるし
どっちもｱﾘっちゃｱﾘだな。

792:nobodyさん
05/12/13 19:54:09
>>790
なるほど、そういうことね。確かに勘違いだわ。
でも、
＞まあそういう風に見るとrequestとuserの非対称性が浮き彫りになるが、俺の場合は結果的にはそういう方針でやってるよ。
getUserもmodel内で使ってるんだ？
ますますわからんくなってきた…

ちなみに
URLﾘﾝｸ(forum.mojavi.org)

ここにあるようなソースはアリなんだよね？

793:nobodyさん
05/12/13 19:56:03
context自体を渡すことがおかしいって言ってるのかと勘違いしてた。

794:nobodyさん
05/12/13 19:59:28
どっちにしても、自分の場合、actionはアダプタじゃなくてmodelで、
action内が複雑になりそうなときmodelに助けを求めるって感じでやってるから。
例えmodel内でgetRequestしても自然なつもりなんだけどなぁ

795:768
05/12/13 20:11:31
じつはagaviでした。
agaviだとみんな食いついてくれないと思ったので.
結果予想以上に皆さんの意見が聞けてよかった。

796:nobodyさん
05/12/13 20:13:34
>>792
うーん、そこのソースのマズイ部分ってとりあえずどこ？ｗ
つーかgetUserをModelでやるのっておかしいかな？言われてみると少し迷うな。
ログインの処理をする専用のModelとかそのままsetAuthenticatedしてるのと、あとはaddCredentialみたいなのもModelの中でちらほらやってしまっている。
もろにビジネスロジックかと思うんだが。

>>794
まあどういう風にやっても間違いってことはないと思う。
Actionにビジネスロジックを書いても結果的には「ロジックとデザインの分離」っていう大元の目的は達成されてるわけだし。

797:nobodyさん
05/12/13 20:28:15
>>795
みなさんというか、２、３人だと思うけどね。自分含めてｗ

798:nobodyさん
05/12/13 20:31:02
>>797
まーこの板はそういうとこだよなｗ

799:nobodyさん
05/12/13 20:34:29
>>796
＞うーん、そこのソースのマズイ部分ってとりあえずどこ？ｗ
その感想自体が答えですｗ　さんきゅｗ

＞ログインの処理をする専用のModelとかそのままsetAuthenticatedしてるのと、あとはaddCredentialみたいなのもModelの中でちらほらやってしまっている。
まぁたしかにgetUserはその辺の機能があるからね。言われれば気持ちはわかる。

ちなみに開発人数はどれくらい？
自分のとこの場合人数が5人で中途半端だから、下手に縛り設けようにもうまく機能しないことが多いんだよね…
フレームワークで許されている権利は使ってよしってことにしてるからってのもあるかも。

800:nobodyさん
05/12/13 20:35:06
userをmodelでいじるのは全然おかしくないと思う
つまるところセッションだし。
requestはブラウザから直接送られてくるデータだから、
いきなりmodelにいじらせるには生々しすぎる感じがするな。

801:nobodyさん
05/12/13 20:40:49
>>800
いや、それだと話がループする…

802:nobodyさん
05/12/13 20:42:35
>>800
そこはmodelで疎結合かどうかの話でしょ？

803:nobodyさん
05/12/13 20:45:33
>>800
＞requestはブラウザから直接送られてくるデータだから、
おいおい大事なget,setAttributeはどこいった？

804:nobodyさん
05/12/13 20:53:12
ひょっとして、getRequest＝ブラウザからのデータで話進められてたの？

805:nobodyさん
05/12/13 21:18:59
ああ、attribute忘れてたw
内部パラメータとしてのattributeならmodelでいじってもおかしくはないよね
viewに渡すためのコンテナとしてなら、
modelから受け取ってactionでこめこめするのがいいと思う

806:nobodyさん
05/12/13 21:31:18
modelでごにょごにょしたものはactionにいくのか？
それともviewか？

807:nobodyさん
05/12/13 21:38:24
>>792-793
model に context が渡ってること自体が気に入らない。理由は >>796 の人が
述べてる理由が近いかな。

>>805
attribute も model じゃ触らない。ビジネスロジックはコントローラに封じ込
めるべきってのは大体の人が賛成してくれると思うけど、attribute を
ビジネスロジックに一切関係ない使用例を見たことがない。もしあるなら
示してくれると、すごく嬉しい。

一般的(≒ Java の世界)にはそういう流れになってない？
モデルは POJO (getter/setter だけのオブジェクト) にして、必要に応じて
AOP でDAO や O/R マッピングしなさい、と。

808:nobodyさん
05/12/13 21:51:40
Javaとは言語仕様も実際の使われ方も違うのに、StrutsやIBMのホワイトペーパーと無理にあわせてもしょうがない。

809:nobodyさん
05/12/13 21:55:50
>>807
＞model に context が渡ってること自体が気に入らない。
えぇ？なんで気に入らないのに
>>796の人と同意なの？
根本的におかしいぞそれ。

810:nobodyさん
05/12/13 21:56:59
>>807
つまり、>>792のソースもおかしいってことだよね？

811:nobodyさん
05/12/13 21:58:05
>>806
actionにいってからviewじゃない？
直接viewにいくのはなんか気持ち悪いな
>>807
Model=POPOなの？
そこまで疎結合にするならModelをextendsする意味がないような…
俺はModel≒ビジネスロジックという認識だった。

812:nobodyさん
05/12/13 22:00:37
一般的ではなくm3やagaviで開発する上での話をしているので、
>>807の話はお門違いなわけだが

813:nobodyさん
05/12/13 22:04:25
mvc的に正しいのはって聞いてるんだから御門違いじゃないだろう

814:nobodyさん
05/12/13 22:05:40
まぁ、お門違いじゃないにしてもおかしなこと言ってるのは確かだな

815:nobodyさん
05/12/13 22:17:24
807は
モデルはフレームワーク自体からも疎結合である方がいいって意味だよね。
考え方は分からないでもないけど
そこまで疎にする必要がはたしてあるのか…
そもそもフレームワークを採用する時点で
全面的な依存を選択しているわけで、
モデルだけを疎結合することにどれほどの意味があるのか

816:nobodyさん
05/12/13 22:17:28
javaが一般的ってのも今は大分微妙になってるけどなぁ

817:nobodyさん
05/12/13 22:19:09
そもそもMVCモデルってそれぞれが密接に関連してるよなぁ
疎を考えるんなら777の言うようにレイヤーパターンで考えたほうが良いと思う
MVCパターンをレイヤーパターンに置き換えると
VCがプレゼンテーション層
Mがドメイン層とデータソース層
それぞれの層は独立していて別の層を知らないのが理想
actionはドメイン層とプレゼンテーション層の中間層かな？
だからactionは
プレゼンテーションからの入力（リクエストパラメータ）を受け取る
ドメインロジックを呼び出す
パラメータをドメインロジックに渡す
ドメインロジックでゴニョゴニョした結果をプレゼンテーションロジックに渡す
こんな流れがいいんじゃないかなぁ
結論、mojaviのModelクラスはｲﾗﾈ

818:nobodyさん
05/12/13 22:19:56
>>815
あぁ、激しく同意…
多分agaviも>>815みたいな思想があってああいう設計になってるんだと思う。

819:nobodyさん
05/12/13 22:23:54
>>817
それだとactionがちょっとややこしくなっちゃわない？

820:nobodyさん
05/12/13 22:33:04
>>815
>>817
おまいらユニットテストしないんですか？
>>819
むしろすっきりする
actionにロジック書くわけじゃないからね
あくまでAPIを呼び出して使うだけ
mojavi的にはこんな感じ
$id = $request->getParameter('id');
$service =　new HogeService();
$hoge = $service->getHoge($id);
$request->setAttribute('hoge', $hoge);

821:nobodyさん
05/12/13 22:34:10
>>817
最後の結論だけ良く分からない
Model＝ドメインロジックで問題なくね？

822:nobodyさん
05/12/13 22:36:37
>>820
autoload.iniが大変なことになりそうだ。

823:nobodyさん
05/12/13 22:49:29
>>820
それってデータベースコネクションはどこでどうやって呼出してんの？

824:nobodyさん
05/12/13 23:00:01
autoload.iniの項目が多いとやっぱり遅くなるの？
おれはできるだけ使わんやつは消しとるよ。

825:nobodyさん
05/12/13 23:04:08
>>821
概念的にはその通りだけど
mojaviのModelクラスに依存したくないという意味でｲﾗﾈということです

>>822
それすごく悩んだけど
自前のクラスローダーで解決したお

>>823
DB接続用クラスをSingletonで作成してどこからでも呼び出せるようにしてるよ
DB::getConnection()みたいな感じで
といってもどこからでも呼び出してるわけじゃないけどね

826:nobodyさん
05/12/13 23:55:30
>>825
なんかもうそれ自分ルールだらけじゃん…
まぁ別にそれが悪いわけではないけど

827:nobodyさん
05/12/13 23:58:11
>>825
＞自前のクラスローダーで解決したお
それはautoload側をいじったのか、ロード関数みたいなのつくったのか

828:nobodyさん
05/12/14 00:01:27
結論
>>825のやってることは、agaviのmodelで解決。
無駄な作業乙

829:nobodyさん
05/12/14 00:34:57
もしかしてSingletonModelってクラス？
Singletonごときでなんであんなものに頼らなきゃいけないのか疑問・・・。
しかもグローバルに呼び出しできなくなるし

830:nobodyさん
05/12/14 00:41:56
PHPでシングルトンってほぼ無意味だよな。

831:nobodyさん
05/12/14 01:27:53
>>830
まあどちらかと言うと、インスタンス２つ以上作ろうとする方が頭どうかしてるもんな。
Controllerとか。

832:nobodyさん
05/12/14 01:43:05
>>830
リクエスト毎にオブジェクトが生成->破棄されるという意味では無意味だな。
ログとかＤＢコネクションとかでは使えるけど、それもグローバル変数に入れとけばいいみたいな。

833:nobodyさん
05/12/14 01:44:31
HTTPリクエスト単位で記憶が失われるPHPでは
シングルトンって「グローバル変数のオブジェクト指向版」みたいな意味しかない気がする
実際に役に立つのはDB接続みたいなリソース使いまわしくらいって印象が……

834:nobodyさん
05/12/14 01:46:05
>>824
クラスが必要なときのみ読みこむようにその設定があるんだし、そんなに気にしなくてもいいのでは。
まぁ少ないほうが早いに決まってるけど。

835:nobodyさん
05/12/14 03:49:22
>>825=>817
そこまで行くとMojaviの理念から外れてるし、それはもうmojaviから派生した>817のフレームワークであって、
とても「mojaviを使っている」とはいえないと思うが。
なのでmojavi(agavi)でMVCどうやるのか(requestをどう扱うか)っていう話においては参考にならない。

>>820
も同様
ただ、ユニットテストはMojaviの致命的な欠点だとおもう。

本題の"request"の扱いについてはModelはＣontrollerを知るべきではない、
そして"request"はControllerである。よって"request"は"Model"で扱うべきではない。
とおもうが。

実際はModelでしかたなくrequest呼び出したことありますごめんなさい。
設計が悪かった。反省してます。

836:nobodyさん
05/12/14 06:37:08
オブジェクトの依存性の話なのか設計上の規約も含めるのか判らん

837:nobodyさん
05/12/14 06:44:24
誰か両方の意見をまとめてくり

838:nobodyさん
05/12/14 07:15:24
いや、なんか感動。
疑問は晴れてないけど。

839:nobodyさん
05/12/14 10:23:55
図にしてみたぞ♥

　　　　　　　Controller
　　　　　　　　　↓
　Request ⇔ Action ⇔ Model ⇔ User,Database
　　　　　　　　　↓
　　　　　　　Controller
　　　　　　　　　↓
　Request ⇔　View　⇔ Model
　　　　　　　　　　　　　 |
　　　　　　　　　　　 ←｜→
　　　プレゼンテー　　｜　　　ドメイン層、データソース層
　　　ション層　　　　　｜
　　　　　　　　　　　　　 |

俺にとってActionとはControllerの一部であり、Requestの受付とModelの呼び出し以外のことはしない。
Action::executeすげーｼﾝﾌﾟﾙｳﾏｰ（AAry）。>>820、>>835と基本的に同じ。
俺にとってModelとはMojavi内で唯一ビジネスロジックを担当する部分である。
ちなみにModel以外はデータ層に触りません！

840:nobodyさん
05/12/14 11:25:24
Modelはどうまとめてる？
俺はOO的にうまいことまとまらない場合は
似たような関数をまとめてお茶を濁してる。

841:nobodyさん
05/12/14 11:38:43
>>839
Model にビジネスロジック入れたら駄目じゃん。話にならん。

842:nobodyさん
05/12/14 11:44:42
>>841
839じゃないけど
俺もModelはビジネスロジックを担当する部分という認識なんだが
きみのいうModelって何？

843:839
05/12/14 11:46:02
>>840
たしかに関数の入れ物に過ぎないModelができちゃうこともあるかもｗ
俺の場合はSean KerrのAction::executeのコメントで、
* Execute any application/business logic for this action.
*
* In a typical database-driven application, execute() handles application
* logic itself and then proceeds to create a model instance. Once the model
* instance is initialized it handles all business logic for the action.
*
* A model should represent an entity in your application. This could be a
* user account, a shopping cart, or even a something as simple as a
* single product.
っていうやつ（mojavi/action/Action.class.php）をけっこう意識しながらやってる。
Modelはentityを表すってのけっこうしっくりきてるかも。
つーか今読み返してみたら、Sean Kerr的にはActionでビジネスロジックもありっていうスタンスっぽいなｗ
ただ、基本はModel＝ビジネスロジックでしょ。

844:nobodyさん
05/12/14 12:08:56
訳：

Actionに対するアプリケーションロジック・ビジネスロジックの実行をします。

よくあるデータベースを用いたアプリケーションでは、execute()の中でアプリケーションロジックを扱い、続いてModelのインスタンスを生成します。
Modelの初期化をしたら後はその中で全てのビジネスロジックを扱います。

Modelはアプリケーション内のエンティティを表すようにすると良いでしょう。
例えば、ユーザーアカウント、ショッピングカートであったり、時には個々の製品といったシンプルなものであることもあるでしょう。

845:nobodyさん
05/12/14 12:12:22
>>844
そうそう。
やっぱり841はビジネスロジックの定義を勘違いしてないか？
エンティティーのメソッドはすなわちビジネスロジックだし。
Model＝ValueObjectと勘違いしてる気がする。

846:nobodyさん
05/12/14 14:28:05
みんな言葉の定義が微妙に違ってるだけだと思う。
というか、レイヤとモデルを微妙に混同してるのかも。

ドメイン層のレイヤにビジネスロジックがあって、
そこで操作されるものがドメインモデル（エンティティ）。

これをそのまま実装に反映させるなら、
ドメインモデルとビジネスロジックは別クラスにするのが自然。
だけどケースバイケースで、ドメインモデルのクラスが
ビジネスロジックのメソッドを持つ実装にするのもあり。
どちらがいいかは一概には言えないと思う。

>>845
それは違うよ。
ValueObjectはどちらかというとドメインモデルではなく
プレゼンテーションモデル。

ドメインモデルをそのままプレゼンテーション層まで引きずってくる
設計方針ならValueObjectぽっく見えるかもしれないけど、
プレゼンテーションモデルをきっちりわける設計方針なら
>>841の言ってるモデルはドメイン層で閉じてるはず。

847:nobodyさん
05/12/14 15:10:04
俺定義で議論してないでPoEAAを読め、ってことだ。

848:nobodyさん
05/12/14 16:18:44
高いから譲ってくれ

849:nobodyさん
05/12/14 16:45:40
O'ReillyのSafari Bookshelfに入れば$19.95で読めるよ。

850:nobodyさん
05/12/14 17:12:47
日本語訳本買ったけど読んでねーや
ValueObjectがプレゼンテーションモデルってどゆ意味？
単に値を持たせるオブジェクトだから
どんな層にでも入ってくる汎用的なパターンだと思うんだが

851:nobodyさん
05/12/14 21:59:44
> 単に値を持たせるオブジェクト

自説を立てるときはそれなりの手順を踏襲してほしい

852:nobodyさん
05/12/15 02:19:59
>>839
>>843を意識してるんなら、Actionはドメイン層、データソース層に入ることもあるだろ

853:nobodyさん
05/12/15 02:23:24
URLﾘﾝｸ(trac.agavi.org)
この公式サンプルも、全然>>839みたいな定義になってねぇし

854:839
05/12/15 03:13:21
>>852
たしかにそうだね。それが
> つーか今読み返してみたら、Sean Kerr的にはActionでビジネスロジックもありっていうスタンスっぽいなｗ
と言った理由なんだけど。
ただ、俺自身はドメイン層の処理はModelでやる方針でやってるって話。
Actionでドメイン層・データソース層に手を出すのも利点があるなら大いに結構だとは思うよ。

>>853
えーっと一応言っておくけど>>839は設計（or実装）方針の話ね。
（それまでの議論の内容も多少加味したつもりなんだが偏見もあるかも・・・）
あと、そこのサンプルは>>844の「ユーザーアカウント」にあたるものをModelとして抽出せずにActionで済ませちゃってるんだね。
だから839と違って見えるってのも無理はないかも。
まあロジックが複雑になってきたらそんなことは言ってられないので俺は認証用に作ったModelを再利用してるよ。
必要ならそのModelをもう一段継承してカスタマイズとかできるのでそこそこ便利だし。

855:nobodyさん
05/12/15 03:28:55
>>841に対して、はじめは何言ってるんだろうこの人…と、>>842と
同じ気持ちでしたが、
URLﾘﾝｸ(www.microsoft.com)
ここを読んでみて>>841の言ってることがよくわかりました。
MVCの図にあるとおり
＞ビューとコントローラの両方がモデルに依存していることに注意してください。ただし、モデルはビューとコントローラのどちらにも依存していません。
モデルは両方に依存していないものなんだね。
そう考えるとたしかに>>839の言ってる図は話にならない。
でも、それを言い出すとAgaviの設計自体がおかしいことになるね。

856:839
05/12/15 03:51:45
>>855
たぶんUMLを見慣れてる人が多いんだろうから誤解を与えたかもしれないけど、>>839は「依存関係」を表してるつもりじゃなかったんだなぁorz
Controller→Action→Controller→Viewってのは制御が移る順番。
他の⇔はデータの受け渡しであって、基本的にはメソッドの呼び出し＋リターンなので制御が移る順番としても解釈できるかも。
>>855が依存関係の話を持ってきてくれたのでそれも考慮すると、⇔の矢印をすべて外側向きに変えたら少しはましになるかな？
矢印の意味は
・依存してる側→依存されてる側
・呼び出し側→呼び出される側
という関係で。（唯一Action→Controllerの部分だけリターンなので矢印の色でも変えてくださいｗ）
「ビジネスロジック」って言葉は俺も再考する必要があるかも。
>>846をもうちょっと咀嚼してみる。

857:nobodyさん
05/12/15 03:53:25
URLﾘﾝｸ(forum.mojavi.org)
こういうの見るとますますわからんくなる…

858:nobodyさん
05/12/15 04:01:35
そこまでごちゃごちゃ深いこと考えなくても、
保守性の高いコードってWebアプリケーションなら結構つくれちゃうからなぁ…
ビジネスロジック云々より、ビジネスや運営自体について考えてたほうがよっぽど金になる

859:839
05/12/15 04:09:49
>>858
俺的もそう思う。どっちでもいーじゃんおまいらｗ、と
でも「間違っている」というつっこみをたくさんいただいたので、ヘコみつつ悪戦苦闘中であります。

860:nobodyさん
05/12/15 04:22:02
>>855
マジでAgaviのView周りってModelに依存性あるの?
ステートレスなWebアプリでは切り離されてるのが当たり前だと思ってたけど。
アクティブモデルにせよオブザーバはかませるっしょ

861:nobodyさん
05/12/15 04:40:08
View生成はクライアントリクエストのみを起点にしているから、
コントローラかアクションにぶらさげることは出来るね

前者はコントローラがMediator（と言ってもモデルかアクションから
データを受け渡すだけ）となり、後者ではアクションはコマンドオブジェクト
（ビジネスロジックとViewの呼び出しをカプセル化したもの）ということになる

どっちもパターンとしてはMVCとは呼ばないんだろうけど
URLﾘﾝｸ(www.martinfowler.com)

Viewがモデルに依存したほうがいいかアクションに依存したほうがいいか
まとまった見解ってある？

862:nobodyさん
05/12/15 04:43:36
>>860
Agavi自体の仕様では依存性は発生しないよ。Modelは一つもなくても動くし。
でもModelを使った時点で依存はゼロではないと思われ。
「切り離す」ってのはいわゆる疎結合にするって意味だとは思うけど、元々依存してしまうものだからせめて疎結合にしましょうって感じじゃなかったっけ？
>>855の言ってるのは、逆向きの依存はゼロってことでしょう。
「Viewを変更したらModelが動かなくなりました」とかしゃれになんないし。
でもModelを変更したらViewに支障が出るのは仕方ない。
それでも最小限にしましょうってのが疎結合だと思う。
オブザーバはContextのことでおｋかな？

863:nobodyさん
05/12/15 05:25:53
依存性＝オブジェクトをNewするかパラメータに取ってメンバにアクセスすること

結合の程度というようなファジーなものは存在しない
Framework界隈で依存性といったらこれのことだと思う

864:nobodyさん
05/12/15 05:52:18
> 結合の程度というようなファジーなものは存在しない
疎結合って結合の程度がゆるいことじゃないの？
つーかどのレスに対してなのか反論なのか何なのかわからんな。

865:863
05/12/15 06:11:06
直上に対するレス

結合にはもちろん程度があるよ
しかし依存性にはそういうものは無くゼロイチだということを言ってみた

>>860と>>862の愛でどうも考えている依存性が違って
かみ合ってないように見えたので

866:nobodyさん
05/12/15 06:12:18
× 愛で
○ 間で

すまん
間違ったものを芽生えさせた

867:nobodyさん
05/12/15 06:12:22
>>860
Modelにするにせよ別もんにしてつくるにしても、
初期のViewだけじゃなにもできんじゃん。
ごてごてタグとテンプレートと定数混ぜることになってしまう。
その辺のモデルもつくるでしょ？ふつう

868:nobodyさん
05/12/15 06:16:08
いや、Mojaviだとビジネスロジックの呼び出しはアクションあたりに集約するのが一般的だと思う
ビュー内でモデルは呼び出したくない

869:nobodyさん
05/12/15 06:20:08
>>868
MVCはもともとそういうものだけどな。View - -> Model

870:862
05/12/15 06:21:54
>>865
そかそか。曖昧な言い方ですまんかった。
基本的には「依存性はゼロイチ」ってのは同意だよ。
だから>>860への答えはViewからModelへの依存性は「あり」。
ただ「切り離されてるのが当たり前」って表現をしてたので、862で「それは疎結合のことであって≠依存性だよね」っていう意味で言った。

>>868
実際にはそうだよなｗ

871:nobodyさん
05/12/15 06:23:49
>>869
パッシブモデルね

872:nobodyさん
05/12/15 09:58:57
モデルをフレームワークから独立させる派は
モデルからUserにアクセスする必要がある時はどうやってるの？

873:nobodyさん
05/12/15 10:10:17
>>872
モデルはフレームワークに依存していない設計なので、
モデルから User にアクセスする必要がない。

874:nobodyさん
05/12/15 10:21:58
extends Modelすらしないってこと？

875:nobodyさん
05/12/15 10:26:14
>>873
DBはどうしてる？

876:nobodyさん
05/12/15 11:14:48
Mojavi系の場合DBみたいな下層にも入ってくるから
フレームワークに依存しない設計がいまいちイメージしにくいな

877:nobodyさん
05/12/15 11:38:55
というか、一度 Mojavi を頭から追い出して一般的な設計の話をしろよｗ
もうあんな設計は古いって…。

878:nobodyさん
05/12/15 11:43:23
話変えたいなら自分から話題を提供すればいいのに

879:nobodyさん
05/12/15 11:51:42
スルーしとけ

880:nobodyさん
05/12/15 11:55:01
Mojaviはたたき台としてまだ価値あるだろ
影響受けてるフレームワークいっぱいあるしな

881:nobodyさん
05/12/15 14:16:48
rails!rails!

882:nobodyさん
05/12/15 15:21:47
PHP on TRAXときたか

883:nobodyさん
05/12/15 21:48:05
S2Baseがいいと思うんだけど、どう？
ValidateやらFilterは自作になるけど、結構いいと思う。

884:nobodyさん
05/12/15 23:18:51
S2PandNで出席者が質問してたが､S2やMapleのDIはどこまでパフォーマンスが出るか疑問｡
プロダクトとしてリリースするなら､自分のところできちんと性能評価をやった方がいいよ｡

885:nobodyさん
05/12/16 00:48:04
もうMojaviでいいや。　

886:nobodyさん
05/12/16 01:35:11
S2をそのままPHPに移植してるのかな

887:768
05/12/16 09:02:11
zend framework待とうよ！

888:nobodyさん
05/12/16 09:14:05
末広がりget, zuzaa

889:nobodyさん
05/12/16 18:13:50
Mojavi初心者なんですが
エスパー募集してもよろしいでしょか？

890:nobodyさん
05/12/16 18:41:40
>>889
ここは語るスレだ。質問はスレ違い。

891:889
05/12/16 18:51:08
>>890
そうですか、失礼しました。(´･ω･｀)

892:nobodyさん
05/12/17 00:42:49
POSTされたデータをDBへupdateする場合はmodelでするの？

893:nobodyさん
05/12/17 01:13:05
>>890
多少質問あったほうが盛り上がるからいいんで内科医？

>>892
基本的にvalidationはactionでやり、DBの扱いはmodelでやってるけど、このスレ読んでたらもしかしたらactionでやったほうがいいのかな？とも思えてきた。

894:nobodyさん
05/12/17 01:30:36
>>893
エスパー募集な質問でもか？

895:nobodyさん
05/12/17 01:39:26
あー、エスパー募集はよろしくない罠ｗ

896:nobodyさん
05/12/17 01:50:31
>>892
modelを作るほど複雑でなく(単なるログとか)、
また他のアクションで同じ機能を利用しないならアクションで済ませてしまってもいいとは思う。

897:nobodyさん
05/12/17 02:02:35
>>896
modelでDBに登録するとしたらサニタイズもmodelでやるってことになる？
でないとmodelがactionに依存してしまう気がするんだけど。

898:nobodyさん
05/12/17 09:32:09
そしたら
サニタイズはactionでやるべきだね。

899:nobodyさん
05/12/17 09:36:15
アクション前にフィルタ処理は済んでるはず
モデルは自身のためのサニタイズは自身で持つ
いずれも定義は括りだす

900:nobodyさん
05/12/17 09:39:35
インプットフィルター → アクションDeバリデーション → モデルサニタイズ

てことか。
実際どこで何をやるんだろ。

901:nobodyさん
05/12/17 10:04:30
つーかModelでDBに書き込む場合、フィルタでサニタイズするのもおかしいじゃん。
てことはActionでDBに書き込むのが正しい？

902:nobodyさん
05/12/17 10:55:36
ありえなす

903:nobodyさん
05/12/17 11:29:14
俺はmodelからdbクラスいじってやってるけど。

904:nobodyさん
05/12/17 12:05:30
mojaviの質問はどこですればいい？

905:nobodyさん
05/12/17 12:12:34
ここですればいいよ
答えが返ってくる時もあれば返ってこない時もあるけど

906:nobodyさん
05/12/17 13:19:27
>>904
あなたの質問がこのスレの命運を決めるかもしれません。
慎重に質問してください。

907:nobodyさん
05/12/17 13:24:57
何のプレッシャーだよw

908:nobodyさん
05/12/17 19:16:29
おい、agaviのサイトがエラーですよ！
URLﾘﾝｸ(www.agavi.org)

909:nobodyさん
05/12/17 20:58:41
>>908
多分5.1にしたんじゃないか

910:nobodyさん
05/12/17 21:00:06
>>908
多分PHP5.1に変えたんだろ
timezone関係の警告でてるし

911:nobodyさん
05/12/17 22:24:03
バージョン上げてからチェックしないとはアホもいいとこだなｗ

912:nobodyさん
05/12/18 03:06:20
>>911
逆だろ
チェックしてからバージョン上げないなんてアホもいいとこだなｗ

913:nobodyさん
05/12/18 03:09:01
まあフレームワークのサイトが
危機管理意識なしでエラーメッセージ垂れ流しっていうのは
あまりよろしくないよなぁ。
そもそも確認すらしないのかと。

914:nobodyさん
05/12/18 06:17:14
あれ、こんなエラー自分の環境じゃ出なかったのに

915:nobodyさん
05/12/18 09:07:58
isSecure()
return true
と

filters.iniで以下設定
[BasicSecurityFilter]
class = "BasicSecurityFilter"
param.comment = "On"

と挙動が違う。

filters.iniで設定すると、controllerの$this->loadModuleFilters($filterChain);
でBasicSecurityFilterがregistされ
BasicSecurityFilterクラスの$controller->forward(LOGIN_MODULE, LOGIN_ACTION);

でLOGIN_MODULEのフォワード無限ループになります。

URLﾘﾝｸ(ozaki.kyoichi.jp)
ここのサイトではちゃんとできているようだけど、
同じようなトラブルにあっている方はいますか？

916:nobodyさん
05/12/18 11:43:36
そのドキュメントは古いよ
BasicSecurityFilterの使用はsettings.iniのUSE_SECURITYで決定する
filters.iniに設定する必要はないよ

917:nobodyさん
05/12/18 14:07:02
o

918:nobodyさん
05/12/18 21:17:43
>>916
ちがうでしょ。
controllerでは下のように条件分岐している。
if (USE_SECURITY && $actionInstance->isSecure()) {

919:nobodyさん
05/12/18 21:42:33
>>911-912
それがPHPクオリティ

920:nobodyさん
05/12/18 22:12:04
>>918
なにが違うんだ？
USE_SECURITY && $actionInstance->isSecure()で
filterChainにSecurityFilterが登録されるわけだが。
なんでfilter.iniで再登録する必要がある？
$actionInstance->isSecure()の意味解ってないだろ

921:nobodyさん
05/12/18 22:48:36
>>920
申し訳ございません。
私が間違ってました。

922:nobodyさん
05/12/18 23:39:16
俺も間違ってた・・・。
再登録以前に、filters.iniにBasicSecurityFilterを登録したら
未認証時に遷移するはずのLoginAction自体にもBasicSecurityFilterが適用されて強制無限ループ。
正確には、forwardが20回再帰すると例外投げるから無限ループにはならないみたいだけど。
すみませんでした。

923:nobodyさん
05/12/18 23:54:26
それそれ！
BasicSecurityFilterは$this->loadModuleFilters($filterChain);
でregistすると、ループする。
（Default_LoginActionにisSecure ()適用したと同等の現象）

いちいちactionでisSecure ()をtrueに書き直すのめんどくさい。

何とかなりませんか

924:nobodyさん
05/12/19 17:48:44
mojaviでadodb+DB_Object使ってる香具師いる?

925:nobodyさん
05/12/19 18:34:07
その組み合わせってなんか変じゃね？

926:nobodyさん
05/12/19 21:25:50
headerを出力したいんだけど、viewにそのまま書いていい？

927:nobodyさん
05/12/19 21:49:37
>>925
変だからやってる香具師いるかなぁと
普通ならPEAR::DB+DB_Objectだろうけど、PEAR::DBってadodbより遅いって言うし。

928:nobodyさん
05/12/19 21:53:15
そこでPDOですよ。

929:nobodyさん
05/12/19 22:05:31
>>925
viewに書くのか。
新しい考えだけど俺はactionに書いてる。
だってviewじゃないし。

930:nobodyさん
05/12/19 22:08:30
>>927
DB_DataObjectは確かに内部でDBを使っているが、
基本的に抽象レイヤーと組み合わせて使うもんじゃないぞ
DB_DataObjectのソースに手を入れるなら別だけど

931:nobodyさん
05/12/19 22:42:40
DB_DataObjectつかうならFlexyもどうぞ。

932:nobodyさん
05/12/20 00:41:08
>>931
Alanさん早くDBDOをFixしてください

933:nobodyさん
05/12/20 02:33:17
というよりみんなは何を使ってるの?

PDO使いたいけどPHP5.1で動かないアプリがあるからムリポ
DB_DataObjectで楽するかadodbで早さを取るか迷い中

934:nobodyさん
05/12/20 12:06:31
agaviサイトまだエラー直ってないじゃん
やる気ねーーー

935:nobodyさん
05/12/20 14:49:28
Mojavi2は　PHP5で動作しますか？

936:nobodyさん
05/12/20 15:07:17
>>933
そもそも PHP を使ってない(ﾟДﾟ)

937:nobodyさん
05/12/20 16:02:57
コスモを感じる

938:nobodyさん
05/12/21 09:02:46
agavi直りますた。

939:nobodyさん
05/12/21 10:14:48
Mojavi < agavi < 江角　< Maple　?

今、Mojavi勉強中なんです。　ながら気になってます。

940:nobodyさん
05/12/21 11:02:52
mojavi以外ならどれでも自分が使いやすいのを使えばいいと思う｡

941:nobodyさん
05/12/21 15:41:11
ありがとう。Mojavi以外を考えたほうがいいのか？　Mojaviを習得するか？
Mojavi覚えるの大変なんですが、何日くらいで慣れますかね？

942:nobodyさん
05/12/21 18:11:03
>>940
なぜmojavi以外?

943:nobodyさん
05/12/21 19:57:44
M3かagaviをすすめる。
オブジェクトを理解するのにちょうど良い。

944:nobodyさん
05/12/21 21:52:51
M3とは？

945:nobodyさん
05/12/21 22:03:21
mojavi3

946:nobodyさん
05/12/21 22:51:55
あれ？ひょっとしてagavi0.10.0が出た話題出てない？

947:nobodyさん
05/12/21 23:05:54
そういえば出てないねぇ。ってかagavi自体の話もあんまり無いような・・・

948:nobodyさん
05/12/22 00:27:18
おお！agavi0.10.0がほんとにでとる！
アップデートしてそのまま使えるんか

949:nobodyさん
05/12/22 12:52:20
agavi Mojavi3 Ethmi Makiko

結局Mojavi2で落ち着きました。その後はまた考えます。

950:nobodyさん
05/12/22 18:28:57
php4つかってんの？
後々のこと考えるとphp5とm3の方がいい。

951:nobodyさん
05/12/23 02:00:04
フレームワークを使うならPHP5＋なんかだろうね。
php4使うぐらいならフレームワーク使わないでいいと思う。
どうせ将来性ないし。

952:nobodyさん
05/12/23 04:49:25
まだまだPHP4が使われつづけると思う。
今のようなPHPの使われ方なら、PHP4で問題ない。

953:nobodyさん
05/12/23 10:19:22
プロシージャ系を想定してるんだろうけど
開発者の一人がもうphp4固有のバグなんかは直さないよというような
ものは使わないほうがいいと思う

954:nobodyさん
05/12/23 10:20:08
というか非OOのフレームワークって見たこと無いや

955:nobodyさん
05/12/23 12:21:16
agavi0.10.0使ってる人、レポよろ

956:nobodyさん
05/12/23 14:01:08
ジングルベルってこういう歌だったの！？
一回目は普通のジングルベルで終わった後、もう一回ボタンをおしてリバースすると・・・
聞こえにくい場合は音を少し大きめに。
URLﾘﾝｸ(media.spikedhumor.com)

957:nobodyさん
05/12/23 14:05:43
>>956
このｽﾚにまでそんなコピペが貼られるご時世かよ

次ページ