トップページ⇒php
1001コメント310KB

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

■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん2007/12/11(火) 23:37:20ID:???
前スレ
http://pc11.2ch.net/test/read.cgi/php/1192604501/
0182nobodyさん2007/12/18(火) 11:41:55ID:???
>>181
勉強しなおせ
0183nobodyさん2007/12/18(火) 11:51:44ID:???
>>182
つり？
0184nobodyさん2007/12/18(火) 12:49:19ID:???
http://ja.wikipedia.org/wiki/Model_View_Controller
0185nobodyさん2007/12/18(火) 13:14:07ID:???
>>181
Modelはテーブルを具現化したものとは限らないとおも。
0186nobodyさん2007/12/18(火) 13:16:50ID:???
>>183
お前がつり？
0187nobodyさん2007/12/18(火) 13:19:19ID:???
ぁ、ぁのう、どなたかフレームワークの構造を簡単に教えてください。
できれば単純なものをコードで書いて頂ければ幸いです。
0188nobodyさん2007/12/18(火) 13:38:03ID:6timmGHR
// ここに前処理

for ($i = 0; $i < 100; $i++) {
// ここに処理
}

// ここに後処理


何かの処理を100回繰り返すフレームワーク
どうだすごいだろ。えへん
0189nobodyさん2007/12/18(火) 13:58:25ID:???
ツッコミづらい
0190nobodyさん2007/12/18(火) 14:23:59ID:???
>>181
簡単に表現すればそんなもんだろ
0191nobodyさん2007/12/18(火) 14:25:56ID:???
>>185
おまえみたいなのが
MにCの処理させたりすんだろうがボケ
きっちりわけろよ！
0192nobodyさん2007/12/18(火) 14:28:57ID:???
単純なコードにするのがフレームワークなのに
フレームワークを単純なコードでかけるか！
0193nobodyさん2007/12/18(火) 14:29:54ID:???
フレームワークばっかり使ってると脳が解けるよ
0194nobodyさん2007/12/18(火) 14:34:08ID:???
>>186
なにも具体的な反論できないとこみると、釣りみたいだな
0195nobodyさん2007/12/18(火) 14:55:05ID:???
>>187
フレームワークのやることは、ユーザからのリクエストに応じて、呼び出す関数やクラスを決定し、実際に呼び出すだけ。それをどれだけ便利にできるかで、各フレームワークの特徴が出る。

<?php
// _actionパラメータの値を調べる。なければ 'index' を使う。
$action = $_REQUEST['_action'];
if (! $action) $action = 'index';

// 関数 do_$action() を実行する（例えば do_index(), do_list() など）。
// これらの関数はアクションを処理するのでアクションハンドラと呼ばれる。
// フォーム値のチェックやDB操作はアクションハンドラの中で行う。
require_once("$action.php");
$funcname = "do_$action";
$ret = $function();

// 配列が返されたら、テンプレートを読み込んで表示する。
// 文字列が返されたら、それをURLとみなし、リダイレクトする。
if (is_array($ret)) {
  $template = "templates/$action.php";
  extract($ret);
  include($template);
} else if (is_string($ret)) {
  header("Location: $ret");
}
?>
0196nobodyさん2007/12/18(火) 15:02:43ID:???
MVCを現実の何かに例えて・・・
とか考えたのだが、いい例が浮かばない・・・

M：銀行（お金貸す側）
V：企業、個人（お金借りる側）
C：国（ルール決める側）

こりゃぜんぜん違うしなー
おまいら何か妙案ありませぬか？
0197nobodyさん2007/12/18(火) 18:37:09ID:???
Mに具体的に何やらせれば良いのかが良くわかりません。
詰まる所、DBやファイルからデータを引っ張って来たり、書き込んだりって言う処理を汎用的に使える様にしたプログラムはMですか？
0198nobodyさん2007/12/18(火) 19:35:00ID:???
どっかからとってきたデータをごにょごにょ加工するのがMで加工したデータをどのテンプレートに渡すか決めるのがCでそれを表示するのがVでつ
0199nobodyさん2007/12/18(火) 19:37:57ID:???
>>184嫁よ
0200nobodyさん2007/12/18(火) 19:40:23ID:???
まあModelかと。
逆にみんなそこまでは判ってて、それだけ考えてピンとこなくなってる奴いるんじゃないかなー
モデル化すべき部品が数えるほどしかない場合って、MVCに拘っても特に嬉しい事ないのよね

M：金全般の定義と、基本的な処理の実装
　・価値クラス
　　・価値クラスを継承した「動産」
　　・価値クラスを継承した「不動産」
　　・価値クラスを継承した「貨幣」
V：金扱う場所や事例
　・不動産屋
　・コンビニのレジ
　・自動販売機
C：制御部分
　・不動産屋がModel扱う場合の処理
　・レジのバイトの応対、帳簿の付け方
　・自動販売機に入った貨幣の形状認識、押された商品と釣り銭の出力

続く
0201nobodyさん2007/12/18(火) 19:41:23ID:???
>>200は>>197宛でした。

続き

>>200の例で、分離による嬉しい事の例：
・法律が変わって資産計上の仕方が変わった場合に、モデルが分離していれば
　基本的な処理の段階に修正を加えて全体の整合性を保てる。
・コンビニがポイント制導入したとしても「コンビニのポイントモデル」を
　追加してコンビニのView/Controller変えることで、「他の事例への影響」を
　完全に切り離せる。
・貨幣偽装事件が相次いで貨幣の形が変わった場合、自動販売機の制御部分を
　変えるだけで済む。他の概念には影響しない。

こういう全体像の場合、モデルを「貨幣」として実装しても組み上げる事は可能。
でも変更対応性は損なわれるし、そもそも証券やら信用やら扱うと「貨幣」を
継承するのは無理があるし、等価的に扱えない。
特にコントローラー側が泣く。
上記の例でも、動産／不動産の価値と実貨幣価値を、「常に整合性が保たれる
ように変換」する作業が必要になってしまう。
で、貨幣ではなく「価値」という概念でモデルを抽象化しとく、と。

冗長になったなぁ。判りやすくはねえな。
人に教える時に悩むのが、実際に何かシステムを作らなくちゃいけないときに
上記の例でいう「価値をくくりだせばいいんだ」という着想をどうやって行う
べきかって話なんだよね。MVCってOOADが要る、っていうかOOADしっかり
考えられる奴はMVC必要なかったりするしな

PHP関係なくてすまん
0202nobodyさん2007/12/18(火) 19:47:31ID:???
>>201
>等価的に扱えない。
「透過的に」の変換ミスです失敬
0203nobodyさん2007/12/18(火) 20:32:41ID:6timmGHR
とりあえず開発が楽になればいいんです。
ということで、PHPフレームワークの話をしましょう！
0204nobodyさん2007/12/19(水) 01:09:23ID:???
>>200-201
「頭でっかちなやつがMVC使っても複雑になるだけ」の好例ww
>>203
結論からいうが、フレームワークを使っても楽にはならない。
フレームワークに使われてる奴が、悦に入って楽になった
気になってるだけ。
02052042007/12/19(水) 01:26:37ID:???
煽られる前に説明しておく。
フレームワークが提供する機能が、たまたまそのまま
実践で使える場合はライブラリ使うのと変わらんが、
フレームワーク全体が密接に繋がってたりするともう駄目。
ZFとか機能切り出してるのは便利な方だが、今度は
フレームワークと言える品物かどうかの怪しくなってくるw
O/Rマッピングとか抽象化とか言うけどよ、実際にサービスが
稼働したあとでDB入れ替えるかっていうとぶっちゃけありえん。
オブジェクト試行wでねじ曲がったお陰で、本当に必要なSQLの
チューニングもできなくなるのが関の山。
ちょっとサブクエリ直せば済む話を、「設計上違う」とか言って
定期バッチで生成するどでかいキャッシュテーブル作って、
本体変えない奴ら。


　　これがフレームワーク厨やMVCモデル厨の実態。


オブジェクト指向厨なんてのもいらっしゃるが、ライブラリ
製作には便利な考え方なのでオブジェクト指向自体は悪くない。
だがOS作る訳じゃあるまいのでフレームワークはままごとと大差ない。
いわばPHPに限らずwebアプリ環境自体がフレームワークなのだよ。
データ構造と関数を整理すればいいだけという事を知ってる奴はからは
>>200みたいな観念論は絶対に出て来ない。
重要なフレームワークがあるとしたらむしろモデル云々よりテストユニットだな。
0206nobodyさん2007/12/19(水) 01:46:09ID:???
あ、言っちゃった
0207nobodyさん2007/12/19(水) 02:36:17ID:???
>>205
頭固いな。
0208nobodyさん2007/12/19(水) 02:39:11ID:???
http://blog.livedoor.jp/dankogai/archives/50970269.html
Perl20周年でPHP憤死ｗｗｗ
0209nobodyさん2007/12/19(水) 02:49:08ID:???
> 結論からいうが、フレームワークを使っても楽にはならない。

には同意。仕様変更があまりない場合ならオブジェクト指向なんてのもｲﾗﾈ。
んでも、仕様変更や似たような機能の追加など、コードを使い回そうとすると
オブジェクト指向で組んだ方が楽。さらに元来関数による手続き言語のPHPで
オブジェクト指向しようとすると、やっぱり土台にフレームワークがほしいわな。

> ちょっとサブクエリ直せば済む話を、「設計上違う」とか言って
> 定期バッチで生成するどでかいキャッシュテーブル作って、

そりゃ別問題だろ。
0210nobodyさん2007/12/19(水) 02:52:08ID:???
なんかPHP、関係スレで頻繁に殺されてるな

PHPを殺すのはPerlでもRubyでもなくPHPユーザかもな
>>200-202とか>>204-205とか
道具の使い方が判ってないだけじゃん
0211nobodyさん2007/12/19(水) 02:53:44ID:???
そうそう、IDEでスケルトンコードを吐くようになるのはいつだろうなぁ。
ZSはZF対応とかなってるけど、スケルトンコードを吐いたりしてくれるわけ?
0212nobodyさん2007/12/19(水) 02:55:39ID:???
フレームワークを使ったら楽になるのは確か。

なぜなら、「フレームワークを使わなくても
すでに自作のフレームワーク相当のものがあるから」
楽だといっている人がいることが何よりの証拠。

自作のフレームワーク相当のものを作らなくて言い分
楽になっている。
0213nobodyさん2007/12/19(水) 02:57:41ID:???
>>211
スケルトンなら、現在のフレームワークはほとんどはいてくれるけど？

それもどっかのライブラリみたいな、コード満載で
IDEで触ること前提の手がつけられないようなものじゃなく、
必要最小限に絞り込まれたわかりやすいスケルトンを生成してくれる。
02142042007/12/19(水) 03:10:05ID:???
>>209
フレームワークとオブジェクト指向は分けて語りたい所。
極端な例で申し訳ないが、「どういう土台が必要か」と言う時に
オブジェクト指向を単なる「変数と関数を同時に保持できる枠」
として運用されちまうと意味がないじゃない。
Webアプリである以上、PHPはページ遷移が免れないからさ、
実運用上ではカプセル化が最も意味がある点だと思うのよ。
>>200を名指ししたのは（もし本人だったらごめん）、
Webアプリの実際の実装や運用でOOADとやらがナンボのもんよって
感じがつきまとうのね。
もちろん、俺の業務にまつわる色んなモンが、俺にバイアス掛けてる
訳だけど、突っ込み貰ってるうちに納得できる事は納得しときたい。
攻撃的な文章投げちまった以上、俺も他者の意見聞いて考えてみたい。

後の指摘は、我ながら反省しつつ同意。
たまたまウチで「設計上違う」の理由として「フレームワーク採用したから」
という話に置き換える奴に苦痛を感じてた折で、別問題な言及に至りました。
申し訳ない。

>>212
そりゃ、必要な物「だけ」が「そのまま」あればいいんだけど、
なかなかそういう各々の利用者全てにご都合主義なフレームワークってなくね？
ライブラリ物なら必要最小限をある程度絞れるけど、大仰な構成になると評価に困る
02152112007/12/19(水) 03:12:38ID:???
>>213
えええっ... (´д｀;) あれ?
IDE(PDTとか)からﾎﾟﾁｯっとするとﾍﾟﾛﾝって出てくるのを期待してたんだけど?
齟齬が発生してたか、俺が無知なだけか... 両方かな?
ちょっとググってくる。
0216nobodyさん2007/12/19(水) 03:16:17ID:???
>>215
IDEから生成したいのか、
スケルトンコードがほしいのか
どっちかはっきりしろｗ
0217nobodyさん2007/12/19(水) 03:19:25ID:???
>>212
> そりゃ、必要な物「だけ」が「そのまま」あればいいんだけど、

「必要なもの」を先に定義してくれないか？

それがたとえ自作のものだったとしても、
自作物に手をつけないで作ったことがあるかい？

世の中にありえないものを、求めない。
どこまでフレームワークに夢見てんだよｗ

フレームワークは便利なものであるが、
完璧なものではない。そもそも世の中に完璧なものはない。
0218nobodyさん2007/12/19(水) 03:23:45ID:???
204。
>>214の捕捉
「土台にフレームワークがほしい」という点だけど、PHP5でもフレームワーク
なしに十分に変更要求に耐えるOOP出来ると思う。
って自分のレス読み直したら、OOP批判が先に出てて誤解招いた。ごめん。

重ねて個人的な状況や見解としては、OOPな枠設計が必要な場合でも、
「利用者全てのご都合主義」に対応しようとしている汎用PHPフレーム
ワークを評価すると、実行オーバーヘッドとスタッフ全員への学習コストが
問題になっちまう。
この場合、プロマネ仕様な場当たり俺俺で十分なのは当然なので、完全な私的状況に乗った言及になってしまっていたと思います。重ねてごめん。

フレームワークの意義に一石投じたかっただけなので、名無しに戻ります。
他の話題の方々、失礼しました。
02192112007/12/19(水) 03:32:09ID:???
>>216
「IDEでスケルトンコードを」って書いてたじゃんw。

出来ることなら、新規プロジェクト生成でディレクトリ構造の選択と生成。
その各ディレクトリで、例えばcontrollersディレクトリで新規phpファイルを
生成したらコントローラ用のスケルトンコードを吐いておいてくれるとか。
0220nobodyさん2007/12/19(水) 03:32:26ID:???
>>217

>「必要なもの」を先に定義してくれないか？

無茶なことを言うなw
定義できないからみんな俺俺で対応する（せざるを得ない）ケースが増える。

＞完璧なものではない。そもそも世の中に完璧なものはない。
どっかで反感買ったようだ。悪い。
仰る通り、不完全でもそのまま乗っかれる（か確実に補足できる）なら、フレームワーク採用に全く問題はないと思う。
02212092007/12/19(水) 03:48:23ID:???
>>218
> 「土台にフレームワークがほしい」という点だけど、PHP5でもフレームワーク
> なしに十分に変更要求に耐えるOOP出来ると思う。

出来るよ。ただ土台があった方が楽が出来ると云うこと。
実行オーバーヘッドは致し方ないけど、学習コストは「コレ」と決まれば
1度で済む。じゃぁ「ドレ」ってことでこのスレにいたりするんじゃないの?
そろそろ俺俺から脱却した方がいい? っていう岐路に立っている人もいるだろうし。
0222nobodyさん2007/12/19(水) 03:56:16ID:???
>>221
うん、まさしく。そこは人それぞれだと思う。
どんどんトーン弱めてしまってるが、俺自身は「このまま俺俺で行くか」「これというフレームワークを提案すべきかどうか」という岐路だと思う。
その上で、ウチで根強い「そもそもフレームワークなんか要らねえ」って意見が、>>201の言う程度のOOADが出来てるスタッフから上がるのね。
それ以外は、悪い意味で繊細で手が付けられないコード書く作業員ばかり。
OOPやMVCの信望者。辛抱者なのかもだが、それは別として。

フレームワーク採用して書き捨てじゃ意味ないからね。
そんな「じゃぁ『ドレ』」で選ぶに値するフレームワークを、機能や設計ではない「意義」の段階から訊いて見たかった。
0223nobodyさん2007/12/19(水) 04:04:26ID:???
>>222追補。
考え方が二つに分かれるという前提を語れてなかったので捕捉。
a:
FW採用によって簡略化でき、スタッフ相互の記述の整合性を保ちやすくなる
b:
FW採用によって簡略化できる代わりに、適用の手間と、学習コスト、サーバ要求、依存関係が発生する

a:、b;、どっちがいいかって話で、その水準は無いなと悩んで、
後者に傾いていたのが>>204,205を書き込んだ精神状態。

なんか煽り口調が反響招いてしまいました。
これもフレームワークの意義を問いたかった故なのです。ご容赦下さい。
もちろん嘘は言ってないので反論ください。
でも明日昼出社なので今は寝ます済みませんおやすみなさい。
02242092007/12/19(水) 06:21:18ID:???
>>222
> そんな「じゃぁ『ドレ』」で選ぶに値するフレームワークを、機能や設計ではない「意義」の段階から訊いて見たかった。

今後ずーっと使い続けられるもの :-)
で、俺俺脱却「もうZFでいいやぁ」って思ってやり始めたところ。

>>223
俺は>>200じゃないし、別に反感を持ってるわけでもないよ。
0225nobodyさん2007/12/19(水) 07:34:15ID:???
コードの自動生成を信じられない俺ガイル。
結局そのできたコードをチェック＆改修しなきゃならんし、それならテキストエディタについてるテンプレ集と変わらん。
0226nobodyさん2007/12/19(水) 07:55:31ID:???
フレームワークの出力を信じられない俺ガイル。
結局その出力されたHTMLをチェック&改修しなきゃならんし、それならテキストエディタでべた書きするのと変わらん。

こうですか？わかりません（＞＜）
0227nobodyさん2007/12/19(水) 08:00:40ID:???
生産力が上がるだけ
0228nobodyさん2007/12/19(水) 08:53:08ID:???
同じ処理を毎度毎度書くほどダルいもんはない
フレーワーク使っとけよ
0229nobodyさん2007/12/19(水) 08:56:25ID:???
オブジェクト指向を理解してないやつほど
フレームワークの良さがわかってない
中規模以上の案件なら間違いなく必須
0230nobodyさん2007/12/19(水) 09:37:31ID:???
オブジェクト指向を未だに理解してなく弱っています。

なんでこのPHPは呼ばれたら、
functionがいきなり実行されてるかさえ理解してなく
フレームワークを使うのです。　だれか教えてください。
0231nobodyさん2007/12/19(水) 09:40:02ID:???
日本人？
0232nobodyさん2007/12/19(水) 09:50:31ID:???
もめん、日本人でつ。
0233nobodyさん2007/12/19(水) 17:45:14ID:???
>>231が読解力ないだけ。
三歳児の作文なんてこの程度が普通だぜ？
0234nobodyさん2007/12/19(水) 20:24:20ID:???
そうなのか。
今時の三歳児ってゆとり以下だな
0235nobodyさん2007/12/20(木) 01:46:50ID:???
ウェブのMVCはまったくオブジェクト指向じゃないもん。
単に役割ごとにクラスに分けてるだけで。もともとMVCはGUIのアプリを作るときに適用する概念。
PHPの場合はパッケージの仕組みがなくて、ソースが混乱しがちなので、大規模になってきたら役割をクラスで分けるというのは整理できていい方法だと思う。
が、それをオブジェクト指向と呼ぶのは強烈な違和感がある。
0236nobodyさん2007/12/20(木) 02:00:32ID:???
namaspaceがサポートされるのはいつごろなんだろうか
5.3ではサポートされるんだよね？
0237nobodyさん2007/12/20(木) 03:56:57ID:???
>>235
切り捨て過ぎじゃね？
ページ遷移伴って破棄される齟齬を埋めるために、永続化関係が語り尽くされた上で今がある訳だしさ。

WOやらStrutsやらがそれぞれのポリシーで上手くやって来た上でRoRとか出て来てるの見ると、オブジェクト指向云々って話じゃなくなってる感じもするな。
如何にlazyに手軽にサブセットDSLやれるかっていう、LL系で実行効率無視したシロモノが好評な時代だし。
結局みんなMVCやりたいのでもOOPやりたいのでもなく、DRYやりたいだけなんじゃないかな。webアプリではなおさら顕著な点だと思う。
クラスを「メソッドとデータをまとめたもの」という切り口だけで扱ってる／しばしば扱わざるを得ない、という状況になると（それが頻繁すぎるんだけど）もうOOPもOOADやらも意味なくなっちまう。
ページ遷移モデルだと、カプセル化使い回しも意義を損ねるし。ポリモルとかPHP自体がそこまで動的に設計できるモンじゃねえし。

そもそも毎ページで色々newされる動きにOOPってマッチしてないかも。
純htmlからJavaScript経由でサーバにアクセスして、永続的オブジェクトにアクセスするサーバサイドスクリプトが走るって動きならまだ納得行くかも。
MVCとか言う前に、クライアント側の設計／サーバサイドの設計をどう見つめ直すかが勝負じゃねえのかな。
0238nobodyさん2007/12/20(木) 09:47:11ID:???
>>235
どうせ、お前のはオレオレOOだろｗ
0239nobodyさん2007/12/20(木) 13:50:29ID:???
ウェブアプリって、データの保存がRDBMS、出力先がHTML。この2つともまったくオブジェクト指向じゃないんだよな。だから、ウェブアプリ自体がオブジェクト指向と相性が悪い。
オブジェクト指向と相性良くしようと思えば、RDBMSじゃなくってOODBにするとか、HTMLを全部DOMで操作するとかにしないといけない。
0240nobodyさん2007/12/20(木) 14:31:22ID:???
そんなことない。
よっぽど複雑なスキーマならともかくテーブルの親子関係もhas_a,has_manyで表現できるし。
中の人はOOPと無縁なSQLで動いてはいるけど。
HTMLは単に整形テキスト出力と割り切るべし。
てかゲームとかもっと複雑なプログラムなんかと比べたら全然楽だってウェブなんか。
0241nobodyさん2007/12/20(木) 16:35:58ID:???
えええええええええええええええええええええええええ
0242nobodyさん2007/12/20(木) 16:52:19ID:???
ゲームもやってたけどゲームのが楽だった。
アルゴリズム考える必要皆無なのがWebのいいところではあるが。
何が怠いってWebはブラウザの挙動がマチマチだったりクライアントの状態がわからないからな。
ゲームなら全部こっちの思い通りにいけるし、OSとかで限定すれば環境も固定だし。
プログラムの深さって意味じゃゲームのが深いかもしれないが、
Webは神経使うんだよな、特にクリティカルなところだと。
ゲームとかちょっと変な動きしてもまあいいっかで済ませられたりするしｗ
ゲームのプレイ自体には金が絡まないしな。
Webだと課金関係とかクレジットとかショップとかだと金が絡むからそこでバグると大変な事になるんで神経使う。
0243nobodyさん2007/12/20(木) 17:03:46ID:???
Webはオンラインで公開するという明確な意義があるんで、動機づけに繋がるんだけど、
ゲームやソフトウェアの開発ってオフラインのイメージが強くてどうも関心が持てない。
誰かのためというよりは、自分のためにシコシコ組んでる感じ。どうでもいいけどさ。
0244nobodyさん2007/12/20(木) 17:46:49ID:???
>>239
> ウェブアプリって、データの保存がRDBMS、出力先がHTML。この2つともまったくオブジェクト指向じゃないんだよな。

出力先がオブジェクト指向なものってなに？

（CUIを含めた）ユーザーインターフェースを持たないプログラム？
0245nobodyさん2007/12/20(木) 17:49:57ID:???
>>239
> オブジェクト指向と相性良くしようと思えば、RDBMSじゃなくってOODBにするとか、HTMLを全部DOMで操作するとかにしないといけない。

うん。だから今のモダンなウェブアプリ開発では、
オブジェクト指向でデータを読み書きできるO/Rマッパーと
HTMLを作成してくれるオブジェクト指向ライブラリを使うのが当たり前。
0246nobodyさん2007/12/20(木) 18:57:15ID:???
> HTMLを作成してくれるオブジェクト指向ライブラリ
ってのがどういうものか今ひとつイメージできない俺。
当たり前、なのか？

まさか全部DOMでノードノードで組み立てるようなもんじゃ無かろうな。
XMLの悪夢再び？
0247nobodyさん2007/12/20(木) 18:59:50ID:???
O/Rは薄皮一枚かぶせて紐付けしてるだけでしょ
その利便性が評価されてるだけで
オブジェクト指向でデータ読み書きって意味不明

OODBって昔から言葉だけ一人歩きしてるしな
実用性あるOODB作るのが難しいとか聞くし

HTML生成も、直書きなテンプレートエンジンばかりだよな
一からDOM組み上げる物view設計って見た事無いぞ
0248nobodyさん2007/12/20(木) 19:07:21ID:???
被った
でもXML/XSLTも構造に対するテンプレートに過ぎないよな。
DOM中のイベントに対してもOO言語側のメソッドとブリッジするくらいじゃないと怪しいかも。
0249nobodyさん2007/12/20(木) 19:17:32ID:???
>>248
そのイベントのブリッジ？は全ての場面で気軽に使うのは現実的でない、ていうAjaxの教訓もあってだな。
一回マウスが「オブジェクト」の上をかすめるだけで何十Kmもパケットが行き来してApacheがアクセスログ
吐いてPHPのオブジェクトを一からnewしてDB接続を作成してって・・・どれだけリッチなんだｗ

UI全部JavaScriptもしくはFlashで作るような形になってしまえってことなのか。結局は
0250nobodyさん2007/12/20(木) 19:33:23ID:???
>>243
規模によるよ。プレステとかコンシューマー系で1年以上かかって作るゲームのがよっぽど大変。
そっちからウェブに来たけどはっきりって楽勝。ママゴトプログラミング。
0251nobodyさん2007/12/20(木) 19:34:03ID:???
webやMVCとOOPの相性悪いからOOPじゃないとか
OODBだとかDOMだとか、もうね、極論過ぎだろ
webプログラミングしたことないアホしかいないのかここは

最低限OOPの理解とFW使ってwebプログラムしてる奴か
これからしようとしてる奴くらいにしてくれよ
正直読むに耐えない
0252nobodyさん2007/12/20(木) 19:41:05ID:???
w
確かにUI層はJS/Flash(+flex|air類)/silverlightの進化に期待できそう。

別のアプローチだと、FastCGIやapache module酷使して画面遷移による切断を回避していく動きもあるな。そういう局面ではもっとOOとして意義ある実装が検討できそうだけどね。

でもどんどん複雑化するな。

結局当面の妥協点としては、フレームワークやO/Rマッパー、テンプレートエンジンを使ってOO関係ない世界に適用していく事になるんだろうなぁ。
0253nobodyさん2007/12/20(木) 19:43:28ID:???
PHPでのwebプログラミングしかしたことのない>>251みたいなやつは結構いると思うがな
そういえばあんまり書き込みないな。がんばってくれ>>251
0254nobodyさん2007/12/20(木) 19:44:36ID:???
>>251
極論しすぎなのとwebprogしたことないのがどう繋がるのかw
無理して何か言おうとしなくていい。
みんな極論通して突っ込みあって遊んでるだけだw
0255nobodyさん2007/12/20(木) 19:45:55ID:???
さっきから俺がもう一人二人いる感が拭えないスレだ
0256nobodyさん2007/12/20(木) 19:51:36ID:???
PHPスレだからPHPだけの奴は悪くないと思うけど、
他の言語環境渡り歩いた結果、貸鯖案件増えてPHPに落ち着いた奴も多いだろうしな
相互理解が進んで欲しいもんだ

PHPの適用範囲が絞られてるせいか、Javaだけの奴とかRubyだけの奴に比べるとこのスレの空気はマシな気もする。
0257nobodyさん2007/12/20(木) 19:54:59ID:???
>>250
コンシューマー系って時代によるだろうけど、俺俺FW作るところから始めてるような時代かしら
そういう視点から見るとPHP系のFWに不満ない？
そういう経緯の方が何使ってるか興味大。設計面や実行効率含めて面白い話が聞けそうな。
0258nobodyさん2007/12/20(木) 20:11:00ID:???
>>256
いや、環境問わずローカルで試しまくれる時代なんだから、言語はある程度触った方がいいだろ。
言語問わず、一つしか知らないってのはプログラマとして問題。
0259nobodyさん2007/12/20(木) 20:45:29ID:???
そろそろOO理解してない馬鹿の独り語りは終わりましたかね？
0260nobodyさん2007/12/20(木) 20:57:22ID:???
本当にOOでView作りたいなら、JavaScript もしくは Flash または Javaアプレットってのは
一つの見識だと思うがな。
PHPはXML（ｗ）でも吐いておけよ、てな感じか。

それをただHTML文字列を出力するライブラリをむりやりOOにしようとして苦しんでるのが
現状、っていう流れじゃないのか？ここ数レスは。
0261nobodyさん2007/12/20(木) 20:58:32ID:???
適材適所を知らない人なので放っておきましょう。
0262nobodyさん2007/12/20(木) 21:08:42ID:???
Flashww
アプレットwww

オブジェクト志向なんちゃらの前に、HTMLのタグ打ちからやり直したらどうよwww
0263nobodyさん2007/12/20(木) 21:15:47ID:???
flashを馬鹿にするやつは素人
0264nobodyさん2007/12/20(木) 21:19:07ID:???
FlashとXMLを並べて語る馬鹿に言われたくねーwww
その辺を判ってない事を馬鹿にしてるんだがw
しかもアプレットは単体で噴けるw　何年前の知識www
0265nobodyさん2007/12/20(木) 21:20:50ID:???
>>264
別にそんなこと語ってないけど
0266nobodyさん2007/12/20(木) 21:25:12ID:???
別人なら悪かったが、文脈読んでからレスしろよ
フラッシュのアクションエディッタでオブジェクト志向とかありえないんだから
0267nobodyさん2007/12/20(木) 21:26:02ID:???
似非OO信者は、
テンプレートを否定しているのか？ｗ

オブジェクト指向 = DOMで操作しないとだめとかアフォだろｗ
0268nobodyさん2007/12/20(木) 21:28:31ID:???
>>264
一つ勉強したいんだが、Flashはサーバからデータを取得するとき、どういう形式で取得するの？
Flashのオブジェクトで取得できれば一番いいんだろうが、それはサーバが限定されるだろうし。
0269nobodyさん2007/12/20(木) 21:33:41ID:???
>>268
スレ違いもほどほどに。普通に変数列にしてクエリで渡す。それ以上はFlash板へどうぞ
0270nobodyさん2007/12/20(木) 21:35:45ID:???
>>205の説明まんまな奴らが湧いて来たな
適材適所だというに
0271nobodyさん2007/12/20(木) 21:36:42ID:???
>>269 thx
つまり俺フォーマットか。それだけじゃ無かろうがなｗ
確かにスレ違いかも

PHPのViewの話だっけ。
ぶっちゃけテンプレートエンジンでいいんじゃね？ OOであろうが無かろうが
所詮 require の延長で、string取得してごにょごにょして echo もしくは eval なんだから
0272nobodyさん2007/12/20(木) 21:39:12ID:???
けど、ほんとにFWに固執してる人はリアルで居るよ。
FWを使うこと自体が目的化しちゃってるやつ。
02732502007/12/20(木) 21:48:54ID:???
>>257
もちろん俺俺フレームワークｗ
ライブラリは使いまくるけど、FWいらんかな。
でもRailsに触れてからは、これが一つのウェブプログラミングの答えだと思った。
symphonyとか使ってみようかな。
MVCとかOOPとかの議論もいいけど、一番大事なのは開発効率。
Javaの人ら見てると、どうだこれはすごい設計技術だろーみたいな
作り手の自己満足ばっかが先行してて開発効率にフォーカスしてない。
Railsはその辺はいい。
ウェブなんかほとんどオママゴトなんだから、これでええやん、みたいな。
0274nobodyさん2007/12/20(木) 21:51:01ID:???
FW以前にOOも一緒かも。
重くなるだけな部分までクラス化してnewしまくるコードに書き換える、オブジェクト指向してるつもりなだけの論外な奴
MVCって概念だけに溺れて自分で作りにくくしてる奴もいるし
0275nobodyさん2007/12/20(木) 21:55:14ID:???
>>273
基本的には同意だが、少し間違うとコピペでいいじゃんコピペが一番速いんだから
いらんことするなってなっちゃう人も多いんだろうなと想像する

何より社長（自分の雇い主）がそれを言い出したときすごく切なくなる
たしかにそれが一番いい局面もあるんだろうけど自分にはまだそのバランスがわからんし
02762502007/12/20(木) 22:22:47ID:???
>>275
いかに似たコードを2度書かないようにするかは永遠の課題。
最近、その辺はコードの自動生成ツールを作ることで回避してたり。
PHPはともかく、JavaやC++みたいに型あると、
型は違うけどコードのフローは同じようなのって、
クラス設計頑張ったり、テンプレート駆使したり、
上にあるDIとか使ったりするんだろうけど、
そうするとどうしても複雑になってくるよね。
何か問題起きたときソース追うのが大変。
そういうとこはコード自動生成ツール作って、そいつに重複コード吐かせちゃう。
コードのフローは素直なのにできる。デバッグも楽になれる。
重複コード書くべきでないってのは、同じコードが点在するのが問題じゃなく、
修正が一箇所で済まなくなるから。
自動生成ツールなら同じコードが散らばってても、直すのはツールだけで済む。
とか自分は思うわけですよ。
OOPで頑張るのもいいけど、こういう逃げ道もありとおもうけどな。
まぁコード自動生成を嫌がる人は多いんだけど。
0277nobodyさん2007/12/20(木) 22:43:32ID:???
コード生成ツールってメンテナ複数人にまたがると意思疎通しにくくなるのがなぁ。
ローカルでツール共有するのも手間だし
俺もサーバサイドでrubyにphp吐かせるとか狂った事やったけど、人とサーバ増やされるというので慌てて組み直したw

その辺railsって手際よくまとめてるよな
railsにPHP吐かせられないもんかなw

OOPやMVCしたいんじゃなく、一元化や効率化を徹底したいだけなんだよな、結局。
OOPやMVC、DIなんかに手法的価値がある局面はあるけど、OOPが目的になっちまうと沈む
0278nobodyさん2007/12/20(木) 23:11:11ID:???
コードの自動生成を認めるには多分条件があって、それは
生成されたコードをいじるなとｗ
それが出来るのなら、>>276もありかと思う

逆に、ただのソーステンプレートとしてコードジェネレータを使う
（いじること前提）なら、ポイントは生成されるソースの行数になりそう

結局railsよくできてるよなってなるんだけどｗ
02792502007/12/20(木) 23:17:16ID:???
>>277
結局人が増えると、各々やり方の差があるからね。
その辺は、フリーになって1人でやる道に逃げて解決w

OOPやるためにOOPやってる人っているよね。
Javaの現場での話だけど、O/RマッパーはあくまでDTOであって、
Modelじゃないって考えの人がいた。
DTOって結局はテーブルと同じ構造だからDBよりの産物で、
ModelでDB的都合は隠蔽すべきって考え。
Table -> DTO(運び屋) -> Model
なわけでDTOではテーブルのカラムのgetter/setter以外の実装は一切許されず。
でも、テーブルとModelの構造は、ほとんどの場合1対1になるわけで。
やることと言えば、ModelのコンストラクタにDTOを渡してModelのメンバに格納。
ModelにDTOと同じgetter/setterを作って中でDTOのgetter/setterを呼び出し。
そして、初めてModelに実装が書ける。
結局、同じ構造のクラス2回作って手間2倍、重さ2倍、メモリ浪費2倍にさせられただけ。
テーブルにカラムが変更したときテーブルが増えたときの作業に萎え萎え。
02802502007/12/20(木) 23:20:22ID:???
>>278
もちろんいじるのは禁止。自動生成ツールはリポジトリで管理。
さらにコミットしたときに自動的にサーバーで自動生成ツールが走る。
なんで勝手に上書きした糞野郎のコードは消えるw
0281nobodyさん2007/12/20(木) 23:58:14ID:???
>>280
それもう自動生成ツールじゃなくね？ライブラリと変わらんじゃないか
すでに生成されたものは面倒でも手動で再生成してマージさせるべきだとおもう
■ このスレッドは過去ログ倉庫に格納されています