- 1 名前：nobodyさん mailto:sage [2008/02/09(土) 10:43:58 ID:???]
- 前スレ
pc11.2ch.net/test/read.cgi/php/1197383840/
- 407 名前：nobodyさん mailto:sage [2008/05/05(月) 03:33:55 ID:???]
- 普通に作ればモデルを作るのが当たり前なんだが・・・。
まあ経験をつめ。
- 408 名前：nobodyさん mailto:sage [2008/05/05(月) 09:50:45 ID:???]
- 変態セッションがいやなら$_SESSION使えばいいじゃない
- 409 名前：nobodyさん mailto:sage [2008/05/05(月) 12:22:34 ID:???]
- >>407
DBやファイル扱わない場合だってあるじゃん・・
- 410 名前：nobodyさん mailto:sage [2008/05/05(月) 12:31:02 ID:???]
- たとえば？
- 411 名前：nobodyさん mailto:sage [2008/05/05(月) 13:45:56 ID:???]
- それはどのFWを使うかというより、
FWを使うべきかどうかを検討する規模の開発だと思う。
生PHP+何かしら必要なライブラリで事足りそう。
- 412 名前：nobodyさん mailto:sage [2008/05/05(月) 15:29:14 ID:???]
- >>407
自分は、>>406じゃないけど、具体的にはどんな感じでモデル組んでます？
オンメモリな処理はともかく、DB上のデータに対しては、SQLの実行はパフォーマンスに
直結するから、内部の処理は隠すべきではないんじゃないかって思うところもあって、
結構悩ましい。
- 413 名前：nobodyさん mailto:sage [2008/05/05(月) 17:17:56 ID:???]
- 内部の処理をモデルの中に隠せばいいのでは？
- 414 名前：nobodyさん mailto:sage [2008/05/05(月) 19:08:40 ID:???]
- だって、最適なSQLって画面とか機能ごとに違うことが多いじゃん。
画面とか機能からの独立性がほとんど無いものを個別に作り上げて、
それをモデルと呼べるのかといえば、かなり疑問。
っていうか、モデルとしてのメリットがほとんどない。
- 415 名前：nobodyさん mailto:sage [2008/05/05(月) 19:21:04 ID:???]
- MVCを勉強しなおしてね。
- 416 名前：nobodyさん [2008/05/06(火) 01:40:18 ID:Db+mgkTm]
- CIのルータが変態なので自前ルータを書いてるんだが
hoge/moge/
と
hoge/moge
を同一と判定すべき？しないべき？
- 417 名前：nobodyさん [2008/05/06(火) 01:45:13 ID:iGu8GQhf]
- すべき
- 418 名前：nobodyさん mailto:sage [2008/05/06(火) 01:54:34 ID:???]
- だよな
ファイルシステムとの類推で考えると
同名のファイルとディレクトリは同階層に存在できないもんな
- 419 名前：nobodyさん mailto:sage [2008/05/06(火) 03:21:15 ID:???]
- どちらでも同じコンテンツにアクセスできることが望ましいと思うが、
どちらかに転送した方が良いと思われ
- 420 名前：nobodyさん mailto:sage [2008/05/06(火) 16:53:07 ID:???]
- 質問スレで知ったんだがRhacoってどうなの？
和製フレームワークっぽいけど
このスレで出たことないよね？
- 421 名前：nobodyさん mailto:sage [2008/05/06(火) 16:54:23 ID:???]
- どうも和製はなぁ。
結局海外製に押し切られる気がする。
だからRubyもいまいち使う気になれない。
- 422 名前：nobodyさん mailto:sage [2008/05/06(火) 16:56:00 ID:???]
- Rhacoのオフィシャルサイトがなんか重いなァ
パフォーマンスでないのかな？
- 423 名前：nobodyさん mailto:sage [2008/05/06(火) 16:59:32 ID:???]
- 結構作り込んである印象
なんでまったく話題に出なかったんだろ？
- 424 名前：nobodyさん mailto:sage [2008/05/06(火) 17:36:05 ID:???]
- >>416
それって他のFWもそうじゃない
その辺があまいのばっかだよなあ
- 425 名前：nobodyさん mailto:sage [2008/05/06(火) 17:47:31 ID:???]
- CIがあまいだけでは？
- 426 名前：nobodyさん mailto:sage [2008/05/06(火) 17:48:55 ID:???]
- >>418
おいおい。index.htmlを忘れているぞ。
hoge/moge/ だとmogeフォルダのindex.html（設定による）を参照すべきだろう？
- 427 名前：nobodyさん mailto:sage [2008/05/06(火) 17:55:43 ID:???]
- >>426
>>417-418は、まさにそう言ってるんだと思うが？
- 428 名前：nobodyさん mailto:sage [2008/05/06(火) 18:14:00 ID:???]
- いや、少し考えてみた。
URLが hoge/moge なら、一番最初に hoge/moge を探すべきだな。rewriteやaliasを含めて。
いきなり hoge/moge/ に書き換えるのは乱暴か
で、そうやって探して hoge/moge が見つからなかった時のみ、hoge/moge/(DirectoryIndex) と
するのが一応は順序かと思った。
>>426はそういう意味かな
- 429 名前：nobodyさん mailto:sage [2008/05/06(火) 18:15:28 ID:???]
- /hoge/mogeでも/hoge/moge/でもどっちでも
mogeがディレクトリ的存在だったら
/hoge/moge/index.html
が表示されるべきで、
その判断はサーバ側でおこなう。
最後の/の有無だけに、エンティティの判断基準を委ねない。
ってことだな
- 430 名前：nobodyさん mailto:sage [2008/05/06(火) 18:16:27 ID:???]
- なんかかぶったｗ
- 431 名前：nobodyさん mailto:sage [2008/05/06(火) 18:20:13 ID:???]
- >>430
結論は反対だけどねｗ
- 432 名前：nobodyさん mailto:sage [2008/05/06(火) 18:22:19 ID:???]
- ん？同じだろ？
- 433 名前：nobodyさん mailto:sage [2008/05/06(火) 18:24:06 ID:???]
- 426…最後の/で判断するよ派
428・429…最後の/で判断しないよ派
これであってる？
- 434 名前：nobodyさん mailto:sage [2008/05/06(火) 18:30:18 ID:???]
- ってか
フレームワークのルータに/hoge/moge/index.htmlが渡ることって考えにくいな
素のリソースはmod_rewriteの設定で直接アクセスされるだろ
- 435 名前：nobodyさん mailto:sage [2008/05/07(水) 00:29:19 ID:???]
- /foo/barへのアクセスは
1./foo/barがファイルであるか確認
2./foo/bar/へリダイレクト（301 Moved Permanently）
が正しい動作のはず。
- 436 名前：nobodyさん mailto:sage [2008/05/07(水) 01:08:20 ID:???]
- 何を基準にした「正しい」動作なの?
- 437 名前：nobodyさん mailto:sage [2008/05/07(水) 01:32:49 ID:???]
- 俺もｵﾓﾀ。いったい何を基準に正しい・正しくないを議論しているのか…
独自アプリのルーティングの話で index.html がどうとかﾜｹﾜｶﾗﾝ
静的ファイルを表示するための httpd を書いていて
mod_dir に酷似した挙動をさせたいということならわからなくもないが、
>>416が聞きたいのはそういうことなのか?
- 438 名前：nobodyさん mailto:sage [2008/05/07(水) 02:53:40 ID:???]
- パスが変わるのでしないべき
妥協点はスラ付きへリダイレクト
が正解
- 439 名前：nobodyさん mailto:sage [2008/05/07(水) 03:22:12 ID:???]
- >>438に賛同。
SEO/SBO という面で考えれば、/ ありと / 無しをアプリ側で同一と見なすべきではない。
ただし、ユーザビリティを考慮すれば、/ 無しを / ありに 301 で転送 (またはその逆) をすることをするとなお良い。
参考 → pmakino.jp/tdiary/20061105.html#p01
- 440 名前：nobodyさん mailto:sage [2008/05/07(水) 06:16:35 ID:???]
- なるほど
たしかにSEO的にリダイレクトする方がいいな
㌧㌧
- 441 名前：nobodyさん mailto:sage [2008/05/07(水) 06:36:20 ID:???]
- >>414
乗り遅れたけど、いい事言ってるなあ。
>>407とか>>415は流行に流されて本質を見失ってるな。
俺はテーブルと一対一になるモデル「じゃない」モデルクラスを作って対処してる。
- 442 名前：nobodyさん mailto:sage [2008/05/07(水) 06:50:57 ID:???]
- >>441
日本語が読みきれん。どっち？
テーブルと1:1に対応することを前提としないモデルクラスを作ってる
テーブルと1:1に対応する、内部の構造が隠蔽されていないから必ずしもモデルとは呼べない、モデルクラスを作ってる
前者だろうとは思うけど、一応。
- 443 名前：nobodyさん mailto:sage [2008/05/07(水) 09:21:36 ID:???]
- はぁ。テーブルと一対一にならなくても
モデルはモデルだろ。
- 444 名前：nobodyさん mailto:sage [2008/05/07(水) 09:47:29 ID:???]
- むしろ、テーブルと1:1になることを前提にするのは、内部構造に対する抽象化が制約されるという意味で、
モデリングとして不適切だと思ってる。
だから自分的には >>443 は自明。
ただ、>>441 の言葉の意味が取りきれなかっただけ。
- 445 名前：nobodyさん mailto:sage [2008/05/07(水) 09:56:24 ID:???]
- クラスで使う例外って
クラスと同じファイルに書く？別にする？
例外クラスを1クラス1ファイル方式にすると
ファイルがとっちらかるよなぁ
- 446 名前：nobodyさん mailto:sage [2008/05/07(水) 12:42:06 ID:???]
- 特定のフレームワーク上でのお作法の話ならずれてるかも知れんが、
自分の場合、自作の例外クラスって、せいぜい2個ぐらい (ユーザ操作系、システム異常系) しか作らない。
どんな例外であれ、rollbackしてエラーメッセージ出して終わりってのがほとんどだから、
クラス分けせずにエラーコードで区別してる。
- 447 名前：nobodyさん mailto:sage [2008/05/07(水) 14:16:49 ID:???]
- 俺はタイプヒンティング使ってcatchするのに結構使うな
- 448 名前：nobodyさん mailto:sage [2008/05/07(水) 20:53:16 ID:???]
- >>446
せっかく例外という便利なものが使えるのに、
古臭く、使いづらく、バグが起こりやすい、
エラーコードを使う理由ってなに？
- 449 名前：nobodyさん mailto:sage [2008/05/07(水) 21:11:53 ID:???]
- >>448
例外の中でエラーコードを使うこと言うこと。
クラスの型で判別してないだけで、例外は使ってる。
- 450 名前：nobodyさん mailto:sage [2008/05/07(水) 21:14:56 ID:???]
- >>449 タイプミス訂正
例外の中でエラーコードを使っていると言う意味。
クラスの型で判別してないだけで、例外処理は使ってる。
- 451 名前：nobodyさん mailto:sage [2008/05/07(水) 21:59:18 ID:???]
- >>445
class なんとか_かんとか_Exception extends なんとか_Exception
{}
だけみたいなファイルが増えてくのはやっぱバカバカしいな
- 452 名前：nobodyさん mailto:sage [2008/05/07(水) 23:57:23 ID:???]
- というかPHPのtry catchはゴミすぎて使う気になれませんよｗ
- 453 名前：nobodyさん mailto:sage [2008/05/08(木) 00:14:58 ID:???]
- 結局catch ～～ で分岐するか、instanseof で分岐するか、
$e->getCode(), $e->getMessage() で分岐するか、の違い
しかないとか思っちゃうんだが、わかってないってことだと
自分でも思う
- 454 名前：nobodyさん mailto:sage [2008/05/08(木) 00:29:40 ID:???]
- MVC要らんな。
長い目で見たら実は激しく開発効率が落ちるよな。
みんなとっくに気付いてるだろ。
もうMVCなんて発掘された化石にしがみつくのはやめようぜ。
テンプレートに全部書くに限る。
冗談抜きで、コピペでいい。
変更は該当ファイルを変更。
追加は新規作成。
そもそもPHPはこの形で爆発的に伸びてきた。
ものすごい速さで「ページ」を量産できてきたわけだ。
PHPと比較してはるかにHTMLを苦手とする他の言語の実装にすりよる必要なんてない。
コードが醜悪で結構。
メンテし難い？
いやいや、HTML部分はどんな初心者でも理解可能だからさっさと読み飛ばすわけだ。
そして残ったPHP処理部分がMVCを捨ててページ単位で完結して書いてある。
完結しているのだから、追っていくだけで全容が分かるわけだ。
汚い素のPHPファイルが開発効率に優れている理由はここにある。
何かを試験的に作るとき、さっさとPHPというテンプレートで書いちゃうだろ。
たぶん、数時間あれば、第三者に見せられる程度の単機能ページを作れるだろ。
その試作品でいいんだよ。
一週間かけたものと何も変わんねえから。
つまりその試作品で50万くらい請求できるわけだ。
あるいは、10万に値下げできるわけだ。
頭冷やそうぜ。
PHPそのものが実利の塊なんだから、無理して加工すんなって。無駄な汗を流すなよ。
どうしても加工してPHPらしくない別フレームワークを作りたければ、C++で本気で作れ。PHPでやるな馬鹿外人。
- 455 名前：nobodyさん mailto:sage [2008/05/08(木) 00:42:41 ID:???]
- >>454
プログラマとしては気に入らないけど、現場レベルだとコピペ嵐の方が修正時の影響範囲が
限定的だから現実的だというのは、認めないわけでもない。
カラシニコフ的アーキテクチャとでも言うべきか。
- 456 名前：nobodyさん mailto:sage [2008/05/08(木) 00:55:28 ID:???]
- >>454
修正が体力勝負になるから嫌気がさすっていうのもあるんだよｗ
ポリシーと一貫性があるならいいが、どうせ修正がかさむにつれ
AとA'とA''とABとA''Bみたいなソースが量産されてくるんだろ
一字一句変えずにコピペできる所なんてそう無い。大概コピペ先で
修正されてdiffとったりしたら目を覆うような作業量になる
それでも、「可能」かどうかをいうなら、修正は可能だし、８割くらいの
作業が速く済む、っていうのはうなずけなくもないけど
- 457 名前：nobodyさん mailto:sage [2008/05/08(木) 02:02:54 ID:???]
- PHPの場合、try catchの例外処理機構が駄目なんじゃ無くって、組み込み関数がエラーで例外吐かないのが糞。
- 458 名前：nobodyさん mailto:sage [2008/05/08(木) 04:09:14 ID:???]
- >>454
なるほど
ベタ書き→PHP
MVC→他の言語
と使い分けてもいいかもね
PHP以外なら何がいいだろ？
- 459 名前：nobodyさん mailto:sage [2008/05/08(木) 05:17:56 ID:???]
- 俺もPHP使ってるけど確かにそういうことを考えたりする。
>>454はちょっと乱暴な文体だけど言いたいことはわかる。
これは何もスパゲティなコード書けということではなくて
もちろんメンテしやすいように努力はするのだけれど
そのために果たしてMVCやオブジェクト指向が必要かどうかといえば
必ずしも必要ではないかもしれない。
我々は何もPHPしか使えないわけではないのだから
PHPを使う時は割り切ってページ単位でディレクトリ階層もわかりやすく
作っても良いのかもしれない。
正直、最近PHPフレームワークについて興味があったんだが、
再度PHPの良さについて考えてみよう。
- 460 名前：nobodyさん mailto:sage [2008/05/08(木) 06:45:47 ID:???]
- テストのしやすさとか
開発効率とか
安定性を求めれば
結局MVCに戻ってくることになる。
おつかれさんｗ
- 461 名前：nobodyさん mailto:sage [2008/05/08(木) 08:00:22 ID:???]
- 実利を求めたらオブジェクト指向に落ち着くだろ
- 462 名前：nobodyさん mailto:sage [2008/05/08(木) 08:20:17 ID:???]
- どうだろうね。プログラマは確保できるけど能力的には怪しいっていう環境なんかだと、
エレガントな設計はむしろ罪悪じゃないかと思うし、残念ながらそういう環境は多い。
逆に言えば >>454 は、人海戦術で対応可能な仕事でないと成立しないんじゃないかとも思うが、
エレガントさをあきらめれば、人海戦術で対応できない仕事なんてそうないし。
- 463 名前：nobodyさん mailto:sage [2008/05/08(木) 08:43:03 ID:???]
- PHPの特徴はPHPとHTMLが混在できるということだよな。
この混在をViewが分離してないので悪と捉えるならば、
PHPの特徴も悪ということになる。
それでそのPHPの特徴を無くしたMVCなフレームワークを使うことになるんだが、
それじゃPHPを使ってる意味とは何なんだろうか。
別の言語のMVCフレームワークでも良いという結論になってしまうんじゃないか。
別にMVCなフレームワークが悪いと言ってるんじゃない。
ただ、PHPの特徴を活かした使い方があるんじゃないだろうか。
昔ながらのロジックとビューをファイルの上下で分割するような次のような使い方でも。
-------------
<?php
//設定や共通関数のinclude
//PHPによる処理
$a = 1;
?>
<html>
...
<?php echo $a; ?>
</html>
- 464 名前：nobodyさん mailto:sage [2008/05/08(木) 09:39:12 ID:???]
- > 別の言語のMVCフレームワークでも良いという結論になってしまうんじゃないか。
そのとおりだよ。
ただ、フレームワークも込みで、どこのレンタルサーバーで動くようなものはPHPしかない。
Rubyは言語辞退は一定な買ったりバージョンが古いし、
Perlはフレームワークや、必要なライブラリをインストールするのに
Shellやある程度の権限がいる。
PHPとPHP製フレームワーク・ライブラリは、ほとんどが
ファイル配置ですむからね。
あぁ、これがPHPを使っている意味かｗ
- 465 名前：nobodyさん mailto:sage [2008/05/08(木) 09:40:21 ID:???]
- Rubyは言語自体入ってなかったりバージョンが古いし、
- 466 名前：463 mailto:sage [2008/05/08(木) 10:10:38 ID:???]
- >>464
そうなんだよ、現実を考えるとPHPを使いたいというよりは
PHPを使わざるを得ない、という感じなんだよ。
そして使わざるを得ないPHPでPHPの特徴を消すようなフレームワークを使う。
このジレンマというかもやもやしたものが俺の中に常にある。
>Rubyは言語辞退は一定な買ったりバージョンが古いし、
>Perlはフレームワークや、必要なライブラリをインストールするのに
>Shellやある程度の権限がいる
これはレンタルサーバ屋によるというか、PHPも最新バージョンを使いたい
（特にセキュリティホール絡みで）時は、結局自分で最新版をコンパイルすることになって
権限やShellが必要になるので、ほんと、レンタルサーバ屋によるとしか言えないな。
- 467 名前：nobodyさん mailto:sage [2008/05/08(木) 11:24:56 ID:???]
- ベタ書き＝PHP＋XREA
MVC＝Python＋Google App Engine
がいいかな？
- 468 名前：nobodyさん mailto:sage [2008/05/08(木) 11:33:59 ID:???]
- 悪くないんじゃね。適材適所？
GoogleAppEngineは本サービスの内容次第だけど
- 469 名前：nobodyさん mailto:sage [2008/05/08(木) 12:49:25 ID:???]
- FWと独立したORMがもっとでてこねーかな
好きなFWに好きなORMを組み合わせるみたいな使い方が一般的になればいいのに
- 470 名前：nobodyさん mailto:sage [2008/05/08(木) 12:54:43 ID:???]
- 直SQLで十分。
- 471 名前：nobodyさん mailto:sage [2008/05/08(木) 13:01:46 ID:???]
- ﾃｨﾝﾎﾟﾆｰの新しいヘルパって
クラスメソッドになったんだっけ？
<?php echo HogeHelper::url_for('default/poge')?>
みたいな風に書くの？長くね？
- 472 名前：nobodyさん mailto:sage [2008/05/08(木) 13:20:40 ID:???]
- >>466
本末転倒になってね？
PHPの（いけてない）特徴を消すのが何が悪いの？
- 473 名前：nobodyさん mailto:sage [2008/05/08(木) 14:41:46 ID:???]
- いけてないPHP？
綺麗事抜きでドラスティックに行きましょうや
ベタ書き＋直SQL ＝ PHP＋XREA
MVC＋ORM ＝ Python＋Google App Engine
簡単にできることを複雑にやる必要はない
Python、Java等と使い分けて適材適所で
- 474 名前：nobodyさん mailto:sage [2008/05/08(木) 14:52:22 ID:???]
- 開発言語なんて自由に選べるものでもないし、
サーバーサイドで複数の言語が混在したシステムなんて考えたくもない。
ただ、PHPの言語仕様がさほど特徴的とも思わない。
自分は標準ライブラリが整備されてて、メジャーだからPHP使ってる。
- 475 名前：nobodyさん mailto:sage [2008/05/08(木) 15:13:05 ID:???]
- >>473
まず、君は何の為にデザインとロジックの分離という
考え方が存在するのか、なぜORMというものが存在するのか、
その理由を知ったほうがいい。
話はそれからだ。
（そのあとで、なぜPHPにはそれが当てはまらないというんだ？と聞く予定）
ついでに、なぜテンプレートを使えば、
RubyやPythonでも、PHPと同じようにHTMLの中にロジックを
書くことが出来るわけだが、なぜその方法を使わないのか。
君はこっちのほうが簡単だ。といいたいんだろう？
- 476 名前：nobodyさん mailto:sage [2008/05/08(木) 21:45:25 ID:???]
- >>475
で、どれがデザインとロジックの分離できてるわけ?
Rails? JSF? Django? どれもできてないじゃん。
実際できるのがあったとして、それはメジャーなん? 使い物になるだけの速さでるの?
できてもない『デザインとロジックの分離』という幻想を抱いて死んでくれ。
おれは断然>>454支持するぜ。
- 477 名前：nobodyさん mailto:sage [2008/05/08(木) 22:39:24 ID:???]
- まあ極端にならんと。
どっちの利点も判らんでもないけど、中庸ってのも考えなきゃ
妥協点ともいうか
たとえ幻想でも雑魚をまとめる旗印にはなるしw
- 478 名前：nobodyさん mailto:sage [2008/05/09(金) 00:59:50 ID:???]
- 自分が楽な作り方を選べばいいじゃん。
一人でちっさなツール作るなら、べたに書けばいいんじゃね？
中規模以上のものを作るにはMVCが作りやすいがね。
- 479 名前：nobodyさん mailto:sage [2008/05/09(金) 02:21:08 ID:???]
- プログラムとは一言でいえば「データ＋処理」
それ以上でもなければ、それ以外でもない
WEBアプリ＝DBラッパー
DOA→ベタ書き＋直SQLで充分
OOA→MVC＋ORMで楽できる
フレームワークは他人の知恵を借用して楽できるツール＝使わなきゃ損
普段フレームワークを使っていれば、逆にフレームワークを使うまでもない状況かどうか判断できるはずだよね？
お問合せメールフォーム１ページ作るのにsymfony使ってますとかは漫才ｗｗｗ
- 480 名前：nobodyさん mailto:sage [2008/05/09(金) 03:21:13 ID:???]
- インプットチェックで異常があったらフォームを再表示みたく、処理結果によって表示するページが
異なったり、複数の処理結果に対して同じページを表示したいことがあるのは普通だから、
ビューを分離するのは良いんだけど、DBアクセスは、同じ処理をしたいことは多くないし、
無理にまとめるとパフォーマンスが劣化するから、モデルとしてまとめることに利点があるのかは疑問。
コントロールも、自分の場合トランザクション前の処理、トランザクション中の処理、トランザクション後の処理、
次のページ取得を呼び出すクラス作って継承する程度で十分間にあってる。
ビューについては、そもそもがベタ書きみたいなもんだし。
フレームワークは、特定のフレームワークが業界内において支配的な立場になり、
その上で動作する使い勝手が良いパーツが流通しなければ、大してメリットなんかないと思ってる。
ソースコードの可読性は考慮すべきだけど、フレームワークを導入しただけで可読性がよくなる
わけじゃないし、フレームワークを導入しただけで大きなメリットがあるわけでもないなら、
フレームワーク使うべきって論はどうかなぁって思う。
- 481 名前：nobodyさん mailto:sage [2008/05/09(金) 13:09:55 ID:???]
- フレームワーク使うべきかどうかってそういう次元の話じゃなくて、
単にフレームワークを使ったほうが楽だから使うだけだよ。
> DBアクセスは、同じ処理をしたいことは多くないし、
同じ処理あるよ。検索処理や、検索結果を扱いやすいように
構造化されたハッシュ・配列に入れる処理。
JOINしたときとか、二次元の表よりも階層化された
配列に入ってくれたほうが楽だよね。
> その上で動作する使い勝手が良いパーツが流通しなければ、大してメリットなんかないと思ってる。
意味がわからん。PEARライブラリとか普通に使えるだろ。
フレームワーク専用のパーツなら、普通に使い勝手が良いパーツが組み込まれている。
だからこそ便利であり、使うんだが。
> フレームワークを導入しただけで可読性がよくなるわけじゃないし
良くある言い方だね。銀の弾丸じゃないならメリットがないとする極端な考え方。
銀の弾丸なんて存在しない。だけど普通の弾丸なら存在する。
弾丸が効かない敵がいたって、効く敵もいるんだから弾丸はあったほうがいいだろ。
フレームワークを導入すると、可読性が良くなる場合もあるし
少しでもメリットがあるのなら、あったほうがいいだろ。
- 482 名前：nobodyさん mailto:sage [2008/05/09(金) 21:42:19 ID:???]
- >>475
>まず、君は何の為にデザインとロジックの分離という
>考え方が存在するのか、なぜORMというものが存在するのか、
>その理由を知ったほうがいい。
>
>話はそれからだ。
なにこのえらそうなバカ。おまえはデザインとロジックの分離ができてるの?
こんだけえらそうに語ってるんだから、きっと完全な分離ができるんだろう。
で、どれを使ったらできるの? Symfony? Cake?
教えて、コーマンチキな475さん
- 483 名前：nobodyさん mailto:sage [2008/05/09(金) 22:56:26 ID:???]
- 「話はそれからだ」ってのは「理由は聞かないで下さいっ >_<」って意味なんだから、そっとしといてやれよ。
- 484 名前：nobodyさん [2008/05/09(金) 23:11:23 ID:a3XtheQg]
- >>482
>>475じゃないけどsymfony+smarty使ったことあるかい？
しかしMVCは良いとしてもO/Rマッパはなんとかならんもんかね
- 485 名前：nobodyさん mailto:sage [2008/05/10(土) 01:24:53 ID:???]
- >>484
あんな糞なもん使ったって何の自慢にもならねーよｗ
まあ、sfSmartyPlugin（だっけか）の品質の問題はともかく、
デザインにもロジックはあるのだよ。
ORMはおかしいよな。テーブルとモデルが一対一になってる。
おかしいのはPropelだけなのかもしんないけど。
そんなの変だよ、当たり前じゃないか、みたいなレスを貰ったのでほっとした。
- 486 名前：484 mailto:sage [2008/05/10(土) 03:06:24 ID:???]
- >>485
>>デザインにもロジックはあるのだよ。
それ言ったらjspも(ry
>>ORMはおかしいよな。テーブルとモデルが一対一になってる。
いや別に。
漏れがどうにかしてほしいと思っているのはpropelの使い方だけ。
doctrineもpropelもSQL文直打ちしていた人からしたら使いづらいと思うんだよね。
executeQuery()使えばいいんだけど、それだとO/Rマッパーの意味ないしな。
>>そんなの変だよ、当たり前じゃないか、みたいなレスを貰ったのでほっとした。
フレームワーク反対派に賛同したつもりはないんだが・・・・・。
ある程度規模でかくなればクラス分割してlib配下に設置してあげるだけでオートロードしてくれたりするから再利用も行いやすい。
フレームワークは結構便利だと思う。
でもそこまででかくならないんだったら別にいらないよなーって感じじゃね。
symfonyぐらいのフレームワーク使うんだったらメリットでかいと思うけどCakePHPやPiece Frameworkレベルだと別になくても良い様な希ガス。
- 487 名前：nobodyさん mailto:sage [2008/05/10(土) 10:23:21 ID:???]
- 小さいのを作るにはフレームワークを使わなくても出来るけど、
大きいのを作るにはフレームワークを使ったほうが便利。
便利な方法と、不便な方法。どちらを選ぶかは
考えるまでも無い。
- 488 名前：nobodyさん mailto:sage [2008/05/10(土) 10:26:41 ID:???]
- >>485
> デザインにもロジックはあるのだよ。
そうだね。でどうしろと？
どうせデザインにロジックがあるのだから、
各自勝手に作れといわんだろ？
あんた極端なんだよ。完璧じゃなければ必要ないとか考えてるだろ。
もう少しバランス感覚養ったほうがいいんじゃないのか？
1か0じゃなくて、どちらのほうが優れているかで話をしろ。
- 489 名前：nobodyさん mailto:sage [2008/05/10(土) 11:47:06 ID:???]
- JavaのApache Wicketというフレームワークは
テンプレートにHTMLを使う。
JSPみたいな独自タグや{hoge}みたいな独自識別子を使わない。
現状のWicketが完璧とは言わないけど（メジャーとは言い難いし）、
その方向性はいいなと思える。
ViewはHTMLのテンプレートを使って
ロジックはどの言語でもいい、みたいなもの（Viewテンプレートとロジックのブリッジみたいなもの？）ができれば
言語やフレームワークごとにViewの独自タグや独自識別子を使い分けなくてよくなると思うんだけどな。
- 490 名前：nobodyさん mailto:sage [2008/05/10(土) 12:08:18 ID:???]
- 即席で作るだけなら生書きの方が速いことも多いが
保守を考えるとフレームワーク使わないときついだろ
- 491 名前：nobodyさん mailto:sage [2008/05/10(土) 22:09:04 ID:???]
- >>485
> ORMはおかしいよな。テーブルとモデルが一対一になってる。
おかしい理由は？
DAOとしての面ではあるテーブルに対する操作が一つのクラスに集約されるから見通しが良くなるが。
- 492 名前：nobodyさん mailto:sage [2008/05/10(土) 22:28:21 ID:???]
- SQLって単体のテーブルごとにアクセスするものではないからだと思う。
パフォーマンスを考慮したSQLとの相性は悪いんじゃなかろうか。
- 493 名前：nobodyさん mailto:sage [2008/05/10(土) 23:26:26 ID:???]
- >>492
結合する処理をモデルに実装するから、そうでもないよ。
例えばユーザを結合したコメント一覧を取得するアクセスロジックをコメントモデルに持たせるとか。
ORMがアソシエーション機能を提供してたりもするし(あまり好きではないけど)。
Someモデルはsomeテーブル以外を知ってはならないということはないと思う。特にActiveRecordでは。
- 494 名前：nobodyさん mailto:sage [2008/05/11(日) 00:27:11 ID:???]
- runkitでaopみたいなことしたかったけど
セッションハンドラに登録したメソッド書き換えたら
segmantation fault出るようになった
やっぱまだ不安定なんだな・・・面白い拡張なんだが
- 495 名前：nobodyさん mailto:sage [2008/05/11(日) 00:39:19 ID:???]
- 俺485。おまいらレスありがとう。
でも書いてもらった日本語がよくわからない。
俺もいいかげんな発言してたので、真面目に書き直しておく。
>>486
お前は本当にsfSmartyViewPluginを使ったのか？
sfSmartyViewPluginを使わないでsymfonyで開発した事があるか？
sfSmartyViewPluginがビューとロジックの分離における有効策と考えてるなら、
それはあまりにもロジックを排除する事に対して神経質になりすぎだと思う。
symfonyは標準ではPHPの構文をテンプレートファイルに記述する。
確かにこの書き方だとHTML内にロジックが書けてしまうので束縛が無い事が嫌かも知れないが、
ビューにはビューを成立させるためのロジックがあっても良いと俺は考える。
- 496 名前：nobodyさん mailto:sage [2008/05/11(日) 00:43:17 ID:???]
- 俺は485なんだけど441でもある。
>>485の後半に書いた事は>>484に言ったというより、過去のレスへの返答だった。
>>442
前者です。
>>443-444
自明だよな。その書き込みを見てほっとしたぜ。
ってことだった。
- 497 名前：nobodyさん mailto:sage [2008/05/11(日) 00:50:47 ID:???]
- つーか休まないと日本語処理能力が低下しまくっていかんな。
>>488
sfSmartyViewPluginよりもsymfony標準のテンプレート書式の方が優れている。
というか、sfSmartyViewPluginは完璧に使い物にならないと心底思う。
sfSmartyViewPluginは足かせにこそなれ、利便性は何も齎してくれない。
反論はあるだろうけど、ビューに制約を課す事とMVCを考慮する事は全く別だと思う。
>>491
結合とはある単一のテーブルが行う処理ではないから。
- 498 名前：nobodyさん mailto:sage [2008/05/11(日) 01:04:31 ID:???]
- 一対一でマッピングされてるからって
そのテーブルに対して「のみ」のモデルじゃない
- 499 名前：nobodyさん mailto:sage [2008/05/11(日) 03:58:08 ID:???]
- いまだにsmartyとか言ってる意味がわからん
検討にすら値しないだろ
- 500 名前：nobodyさん mailto:sage [2008/05/11(日) 04:09:26 ID:???]
- 結局viewヘルパってどれがいいんだろうな？
・関数
・クラスメソッド
・$this(viewクラスあるいはcontrollerクラスのインスタンス）のメソッド
・$this以外の、view空間にassignされたオブジェクトのメソッド
個人的には最後のものに可能性を感じるが・・・
状態を持ちやすい、動的に変化させやすいという意味で。
複数のクラスのメソッドを集めるmixin的な機能が要りそう。
そこがキレイにできれば・・
- 501 名前：484 mailto:sage [2008/05/11(日) 05:00:31 ID:???]
- >>495
>>お前は本当にsfSmartyViewPluginを使ったのか？
>>sfSmartyViewPluginを使わないでsymfonyで開発した事があるか？
当たり前
>>それはあまりにもロジックを排除する事に対して神経質になりすぎだと思う。
おまい日曜プログラマ？プロジェクト内にテンプレート側にがちごりでロジック書くウンコいたらどうすんの？
デザイン変更したい～なんてお客さんから要望あったらデザイナーにテンプレート渡すだろ？
テンプレート側にロジックかかれたら・・・・・後はわかるよな。
使わなくていいんだったら漏れもつかわねーよ。プラグイン入れるのﾏﾝﾄﾞｸｾ
- 502 名前：nobodyさん mailto:sage [2008/05/11(日) 08:41:33 ID:???]
- >>484
>symfony+smarty使ったことあるかい？
smartyで「デザインとロジックの分離」が実現できるとでも思ってるの? バカ?
>>485
> デザインにもロジックはあるのだよ。
そのとーり。WicketやMayaaやTapestryでは確かに「デザインとロジックの分離」ができるけど、smartyなんかじゃ全然できない。
>>488
> そうだね。でどうしろと？
おまえはなにもするな。smartyごときで「デザインとロジックの分離」とか偉そうに語るな。
> あんた極端なんだよ。完璧じゃなければ必要ないとか考えてるだろ。
完璧にほど遠いものをさも完璧なように語るおまえがバカなだけ。
PHPにはWicketもMayaaもないんだから、デザインの分離なんか考えるだけ無駄。
> もう少しバランス感覚養ったほうがいいんじゃないのか？
> 1か0じゃなくて、どちらのほうが優れているかで話をしろ。
他人の言葉をうのみにしているおまえこそ、もっと現実をみたほうがいい。
実現できてもないことに、1も0もないだろ。バッカじゃない?
- 503 名前：nobodyさん mailto:sage [2008/05/11(日) 08:51:20 ID:???]
- >>498
そういう解釈をいれないといけないあたり、相性が悪いんじゃないかと。
出来ないって話はしてないつもり。
そもそもモデリングってのは本質的ではないものを隠蔽したり相殺したりして
扱いやすくするものだと理解してるんだが、パフォーマンス的なことを考えると
SQLはそれ自体が本質的で、隠蔽されるべき対象ではないと思う。
機能的なことだけ考えれば良いのなら、SQLを隠蔽するのは正しいだろうけど、
それは贅沢だなぁって思う。
- 504 名前：nobodyさん mailto:sage [2008/05/11(日) 09:50:03 ID:???]
- モデリングの時点でオブジェクト間の関連は定義されるんだから相性が悪いということはないと思うけどな。
設計(仕様)上、記事テーブルがユーザテーブルに依存するなら、記事モデルがユーザモデル(テーブル)を知っていていいし、依存してもいい。
ただ、今までORMレイヤをリリースしてきた人達が「SQLを書かなくていいよ！楽チンだよ！」ってところを押しすぎたのは良くない。
複雑なフェッチが必要な場合はSQLを発行して結果を返すメソッドをモデルに持たせればいいのに、
「(極端に言えば)SQLを書いちゃいけない」という固定観念のもと、SQL以上に複雑な手続きによるフェッチだったり、
複数回SQLが発行されることを厭わない実装がある。
バランスとれればいいんじゃないかな。多くの部分ではSQL書かずに楽するし、SQLが必要なら(モデル内に)SQLを書く。
SQL書いたらORMが謳う「簡単なデータベースの切り替え」ができなくなるって？
大丈夫。開発中にデータベースが変更になることはまずないし、「ついで」程度の機能でしかない。
- 505 名前：nobodyさん mailto:sage [2008/05/11(日) 13:40:27 ID:???]
- オープンソースのフレームワーク開発ってどういうビジネスモデルなんだろ？
symfonyとかciは企業が作ってるけど
どこで利益あげてるのかな？
知名度を上げて受注を増やす形？
- 506 名前：nobodyさん mailto:sage [2008/05/11(日) 14:20:23 ID:???]
- ひょっとしてそれはギャグで（ｒｙ
- 507 名前：nobodyさん mailto:sage [2008/05/11(日) 14:24:05 ID:???]
- いやギャグじゃないよ
どこからか金が環流しないと時間と労力投入できないじゃん
|
 |
