【PHP】フレームワークについて語るスレ9【総合】
■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん
2007/12/11(火) 23:37:20ID:???http://pc11.2ch.net/test/read.cgi/php/1192604501/
0151nobodyさん
2007/12/16(日) 16:27:32ID:???文字エンコードってどれ使ってる？
一昔前はEUC-JPが常識って感じだったけど、最近はUTF-8が多いんだろうか。
FrameworkによってはUTF-8使うのを半ば必須みたいに書いてるのもあるし。
昔はPHPで検索かけて色々サンプルとか見ても、設定の例もサンプルの中身も大抵EUC-JPだったよね。
自分はその頃からそれがなんだか嫌で、ASP.NETもやってるんだけどこっちはUTF-8が相性良くて
これといって文字コード関係で悩まされた事がないんで好きなんだけど
やっぱまだEUC派って多い？
JavaとPHPは初めてやった時やたらエンコード関連の文字化けで悩まされた・・・
特にアップロード機能とかメールとか絡むと。
これからはPHPでもUTF-8がデファクトスタンダードになっていくのかなあ。
なっていって欲しいけど。
0152nobodyさん
2007/12/16(日) 17:11:25ID:???ていうか知ってる奴いるのか
0153nobodyさん
2007/12/16(日) 17:18:18ID:???これか
公開してない割りにはドキュメント整備しすぎだろ
0154nobodyさん
2007/12/16(日) 17:23:39ID:???0155nobodyさん
2007/12/16(日) 17:29:14ID:???相手先でそれが使えるとは限らないから。
単体で動くのが一番楽で環境依存しないからいい。
0156nobodyさん
2007/12/16(日) 17:45:35ID:???0157nobodyさん
2007/12/16(日) 20:07:08ID:???0158nobodyさん
2007/12/16(日) 20:14:36ID:???0160nobodyさん
2007/12/16(日) 21:22:28ID:???0161nobodyさん
2007/12/16(日) 21:43:10ID:???0162nobodyさん
2007/12/16(日) 21:54:20ID:???0163nobodyさん
2007/12/16(日) 23:19:35ID:???PostgreSQL7.xとEUCでやってたらつっこめない文字とかあるし。
0164163
2007/12/16(日) 23:25:50ID:???㈱とかをPDTだとEUCで保存できない。
㈱って入力されたら「株式会社」と変換したいだけなんだが。
0165nobodyさん
2007/12/16(日) 23:57:50ID:???SquirrelMailに攻撃コード埋め込まれてPHP普通に脂肪ｗｗｗ
0167nobodyさん
2007/12/17(月) 00:20:03ID:???FWに依存してるのは良くてPEARに依存するのがダメな理由は？
相手先で使えると限らないのはFWも一緒では？
>>157
んなこたない
ターミナルUTF-8にしてそれが原因でUNIX上で困った事とか特にない
0169nobodyさん
2007/12/17(月) 01:59:39ID:???------------------------------------------------
□ 962 nobodyさん [sage] 2007/12/09(日) 22:40:08 ID:???
>>960
それ（変換とか）よりもSJISの場合はダメ文字絡みがやっぱり一番大きいと思うんだ。
シングルバイト圏の作るライブラリとか。
大体文字コードの変換なんてかつては「必要悪」だったのが今やただのオーバヘッドや
不具合の温床だと思ってそれほど間違ってるかな。
要はWindowsさえ次のOSでごにょごにょやってSJIS(CP932？)捨ててくれれば、問題の
大部分はweb系に関してはほとんど片づきそうな気もする。
------------------------------------------------
これEUCも一緒だろ。ダメ文字が無いってだけで、ラテン文字入ったら文字コード変換は必須。
お前ら直近でループしてるんじゃねえよｗ
0170nobodyさん
2007/12/17(月) 08:02:39ID:???すべてUTF-8に統一すればいいんだよ
0171nobodyさん
2007/12/17(月) 08:03:59ID:???激しくスレ違いだけどな！
0172nobodyさん
2007/12/17(月) 09:28:32ID:???1つ1つのメソッドがやってることはコメントに書いてくれてるんだが、それがどういう順番に動作して
いるのか意味不明。
コントローラ内に平気でSQL直書きしてあったり、SQL文組み立てのメソッドがあったりする。
モデルは単にネイティブ関数のラップ。（Pear::DBもどきをモデルと言い張ってるorz）
それのどこがMVCやねん！と突っ込みたくなるが、コメントには「これはMVCフレームワーク」とか
書いてあるｗ
中途半端なコメントじゃない系統立てたドキュメント残してくれるならともかく、自己満FWを使ったなら
改修も一生面倒見てほすぃ。
0173nobodyさん
2007/12/17(月) 09:33:34ID:???リクエスト出して最後に何か吐いて終わりなんだし。
スパゲティになりようがない。
php1枚にプログラムもHTMLべた書きのウンコソースメンテするよりはマシだと思うぞ。
0174nobodyさん
2007/12/17(月) 11:58:48ID:???どこでもいつでもすぐデバッグできるよ
0175nobodyさん
2007/12/17(月) 22:58:15ID:???0176nobodyさん
2007/12/17(月) 23:10:02ID:???0177nobodyさん
2007/12/18(火) 09:33:48ID:???0178nobodyさん
2007/12/18(火) 09:38:53ID:???0179nobodyさん
2007/12/18(火) 09:53:40ID:???0181nobodyさん
2007/12/18(火) 10:37:47ID:???V->HTML制御
C->MとVをコントロールする中間管理職
0184nobodyさん
2007/12/18(火) 12:49:19ID:???0187nobodyさん
2007/12/18(火) 13:19:19ID:???できれば単純なものをコードで書いて頂ければ幸いです。
0188nobodyさん
2007/12/18(火) 13:38:03ID:6timmGHRfor ($i = 0; $i < 100; $i++) {
// ここに処理
}
// ここに後処理
何かの処理を100回繰り返すフレームワーク
どうだすごいだろ。えへん
0189nobodyさん
2007/12/18(火) 13:58:25ID:???0192nobodyさん
2007/12/18(火) 14:28:57ID:???フレームワークを単純なコードでかけるか！
0193nobodyさん
2007/12/18(火) 14:29:54ID:???0195nobodyさん
2007/12/18(火) 14:55:05ID:???フレームワークのやることは、ユーザからのリクエストに応じて、呼び出す関数やクラスを決定し、実際に呼び出すだけ。それをどれだけ便利にできるかで、各フレームワークの特徴が出る。
<?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:???とか考えたのだが、いい例が浮かばない・・・
M：銀行（お金貸す側）
V：企業、個人（お金借りる側）
C：国（ルール決める側）
こりゃぜんぜん違うしなー
おまいら何か妙案ありませぬか？
0197nobodyさん
2007/12/18(火) 18:37:09ID:???詰まる所、DBやファイルからデータを引っ張って来たり、書き込んだりって言う処理を汎用的に使える様にしたプログラムはMですか？
0198nobodyさん
2007/12/18(火) 19:35:00ID:???0200nobodyさん
2007/12/18(火) 19:40:23ID:???逆にみんなそこまでは判ってて、それだけ考えてピンとこなくなってる奴いるんじゃないかなー
モデル化すべき部品が数えるほどしかない場合って、MVCに拘っても特に嬉しい事ないのよね
M：金全般の定義と、基本的な処理の実装
・価値クラス
・価値クラスを継承した「動産」
・価値クラスを継承した「不動産」
・価値クラスを継承した「貨幣」
V：金扱う場所や事例
・不動産屋
・コンビニのレジ
・自動販売機
C：制御部分
・不動産屋がModel扱う場合の処理
・レジのバイトの応対、帳簿の付け方
・自動販売機に入った貨幣の形状認識、押された商品と釣り銭の出力
続く
0201nobodyさん
2007/12/18(火) 19:41:23ID:???続き
>>200の例で、分離による嬉しい事の例：
・法律が変わって資産計上の仕方が変わった場合に、モデルが分離していれば
基本的な処理の段階に修正を加えて全体の整合性を保てる。
・コンビニがポイント制導入したとしても「コンビニのポイントモデル」を
追加してコンビニのView/Controller変えることで、「他の事例への影響」を
完全に切り離せる。
・貨幣偽装事件が相次いで貨幣の形が変わった場合、自動販売機の制御部分を
変えるだけで済む。他の概念には影響しない。
こういう全体像の場合、モデルを「貨幣」として実装しても組み上げる事は可能。
でも変更対応性は損なわれるし、そもそも証券やら信用やら扱うと「貨幣」を
継承するのは無理があるし、等価的に扱えない。
特にコントローラー側が泣く。
上記の例でも、動産／不動産の価値と実貨幣価値を、「常に整合性が保たれる
ように変換」する作業が必要になってしまう。
で、貨幣ではなく「価値」という概念でモデルを抽象化しとく、と。
冗長になったなぁ。判りやすくはねえな。
人に教える時に悩むのが、実際に何かシステムを作らなくちゃいけないときに
上記の例でいう「価値をくくりだせばいいんだ」という着想をどうやって行う
べきかって話なんだよね。MVCってOOADが要る、っていうかOOADしっかり
考えられる奴はMVC必要なかったりするしな
PHP関係なくてすまん
0203nobodyさん
2007/12/18(火) 20:32:41ID:6timmGHRということで、PHPフレームワークの話をしましょう！
0204nobodyさん
2007/12/19(水) 01:09:23ID:???「頭でっかちなやつがMVC使っても複雑になるだけ」の好例ww
>>203
結論からいうが、フレームワークを使っても楽にはならない。
フレームワークに使われてる奴が、悦に入って楽になった
気になってるだけ。
0205204
2007/12/19(水) 01:26:37ID:???フレームワークが提供する機能が、たまたまそのまま
実践で使える場合はライブラリ使うのと変わらんが、
フレームワーク全体が密接に繋がってたりするともう駄目。
ZFとか機能切り出してるのは便利な方だが、今度は
フレームワークと言える品物かどうかの怪しくなってくるw
O/Rマッピングとか抽象化とか言うけどよ、実際にサービスが
稼働したあとでDB入れ替えるかっていうとぶっちゃけありえん。
オブジェクト試行wでねじ曲がったお陰で、本当に必要なSQLの
チューニングもできなくなるのが関の山。
ちょっとサブクエリ直せば済む話を、「設計上違う」とか言って
定期バッチで生成するどでかいキャッシュテーブル作って、
本体変えない奴ら。
これがフレームワーク厨やMVCモデル厨の実態。
オブジェクト指向厨なんてのもいらっしゃるが、ライブラリ
製作には便利な考え方なのでオブジェクト指向自体は悪くない。
だがOS作る訳じゃあるまいのでフレームワークはままごとと大差ない。
いわばPHPに限らずwebアプリ環境自体がフレームワークなのだよ。
データ構造と関数を整理すればいいだけという事を知ってる奴はからは
>>200みたいな観念論は絶対に出て来ない。
重要なフレームワークがあるとしたらむしろモデル云々よりテストユニットだな。
0206nobodyさん
2007/12/19(水) 01:46:09ID:???0208nobodyさん
2007/12/19(水) 02:39:11ID:???Perl20周年でPHP憤死ｗｗｗ
0209nobodyさん
2007/12/19(水) 02:49:08ID:???には同意。仕様変更があまりない場合ならオブジェクト指向なんてのもｲﾗﾈ。
んでも、仕様変更や似たような機能の追加など、コードを使い回そうとすると
オブジェクト指向で組んだ方が楽。さらに元来関数による手続き言語のPHPで
オブジェクト指向しようとすると、やっぱり土台にフレームワークがほしいわな。
> ちょっとサブクエリ直せば済む話を、「設計上違う」とか言って
> 定期バッチで生成するどでかいキャッシュテーブル作って、
そりゃ別問題だろ。
0210nobodyさん
2007/12/19(水) 02:52:08ID:???PHPを殺すのはPerlでもRubyでもなくPHPユーザかもな
>>200-202とか>>204-205とか
道具の使い方が判ってないだけじゃん
0211nobodyさん
2007/12/19(水) 02:53:44ID:???ZSはZF対応とかなってるけど、スケルトンコードを吐いたりしてくれるわけ?
0212nobodyさん
2007/12/19(水) 02:55:39ID:???なぜなら、「フレームワークを使わなくても
すでに自作のフレームワーク相当のものがあるから」
楽だといっている人がいることが何よりの証拠。
自作のフレームワーク相当のものを作らなくて言い分
楽になっている。
0213nobodyさん
2007/12/19(水) 02:57:41ID:???スケルトンなら、現在のフレームワークはほとんどはいてくれるけど？
それもどっかのライブラリみたいな、コード満載で
IDEで触ること前提の手がつけられないようなものじゃなく、
必要最小限に絞り込まれたわかりやすいスケルトンを生成してくれる。
0214204
2007/12/19(水) 03:10:05ID:???フレームワークとオブジェクト指向は分けて語りたい所。
極端な例で申し訳ないが、「どういう土台が必要か」と言う時に
オブジェクト指向を単なる「変数と関数を同時に保持できる枠」
として運用されちまうと意味がないじゃない。
Webアプリである以上、PHPはページ遷移が免れないからさ、
実運用上ではカプセル化が最も意味がある点だと思うのよ。
>>200を名指ししたのは（もし本人だったらごめん）、
Webアプリの実際の実装や運用でOOADとやらがナンボのもんよって
感じがつきまとうのね。
もちろん、俺の業務にまつわる色んなモンが、俺にバイアス掛けてる
訳だけど、突っ込み貰ってるうちに納得できる事は納得しときたい。
攻撃的な文章投げちまった以上、俺も他者の意見聞いて考えてみたい。
後の指摘は、我ながら反省しつつ同意。
たまたまウチで「設計上違う」の理由として「フレームワーク採用したから」
という話に置き換える奴に苦痛を感じてた折で、別問題な言及に至りました。
申し訳ない。
>>212
そりゃ、必要な物「だけ」が「そのまま」あればいいんだけど、
なかなかそういう各々の利用者全てにご都合主義なフレームワークってなくね？
ライブラリ物なら必要最小限をある程度絞れるけど、大仰な構成になると評価に困る
0215211
2007/12/19(水) 03:12:38ID:???えええっ... (´д｀;) あれ?
IDE(PDTとか)からﾎﾟﾁｯっとするとﾍﾟﾛﾝって出てくるのを期待してたんだけど?
齟齬が発生してたか、俺が無知なだけか... 両方かな?
ちょっとググってくる。
0217nobodyさん
2007/12/19(水) 03:19:25ID:???> そりゃ、必要な物「だけ」が「そのまま」あればいいんだけど、
「必要なもの」を先に定義してくれないか？
それがたとえ自作のものだったとしても、
自作物に手をつけないで作ったことがあるかい？
世の中にありえないものを、求めない。
どこまでフレームワークに夢見てんだよｗ
フレームワークは便利なものであるが、
完璧なものではない。そもそも世の中に完璧なものはない。
0218nobodyさん
2007/12/19(水) 03:23:45ID:???>>214の捕捉
「土台にフレームワークがほしい」という点だけど、PHP5でもフレームワーク
なしに十分に変更要求に耐えるOOP出来ると思う。
って自分のレス読み直したら、OOP批判が先に出てて誤解招いた。ごめん。
重ねて個人的な状況や見解としては、OOPな枠設計が必要な場合でも、
「利用者全てのご都合主義」に対応しようとしている汎用PHPフレーム
ワークを評価すると、実行オーバーヘッドとスタッフ全員への学習コストが
問題になっちまう。
この場合、プロマネ仕様な場当たり俺俺で十分なのは当然なので、完全な私的状況に乗った言及になってしまっていたと思います。重ねてごめん。
フレームワークの意義に一石投じたかっただけなので、名無しに戻ります。
他の話題の方々、失礼しました。
0219211
2007/12/19(水) 03:32:09ID:???「IDEでスケルトンコードを」って書いてたじゃんw。
出来ることなら、新規プロジェクト生成でディレクトリ構造の選択と生成。
その各ディレクトリで、例えばcontrollersディレクトリで新規phpファイルを
生成したらコントローラ用のスケルトンコードを吐いておいてくれるとか。
0220nobodyさん
2007/12/19(水) 03:32:26ID:???>「必要なもの」を先に定義してくれないか？
無茶なことを言うなw
定義できないからみんな俺俺で対応する（せざるを得ない）ケースが増える。
＞完璧なものではない。そもそも世の中に完璧なものはない。
どっかで反感買ったようだ。悪い。
仰る通り、不完全でもそのまま乗っかれる（か確実に補足できる）なら、フレームワーク採用に全く問題はないと思う。
0221209
2007/12/19(水) 03:48:23ID:???> 「土台にフレームワークがほしい」という点だけど、PHP5でもフレームワーク
> なしに十分に変更要求に耐えるOOP出来ると思う。
出来るよ。ただ土台があった方が楽が出来ると云うこと。
実行オーバーヘッドは致し方ないけど、学習コストは「コレ」と決まれば
1度で済む。じゃぁ「ドレ」ってことでこのスレにいたりするんじゃないの?
そろそろ俺俺から脱却した方がいい? っていう岐路に立っている人もいるだろうし。
0222nobodyさん
2007/12/19(水) 03:56:16ID:???うん、まさしく。そこは人それぞれだと思う。
どんどんトーン弱めてしまってるが、俺自身は「このまま俺俺で行くか」「これというフレームワークを提案すべきかどうか」という岐路だと思う。
その上で、ウチで根強い「そもそもフレームワークなんか要らねえ」って意見が、>>201の言う程度のOOADが出来てるスタッフから上がるのね。
それ以外は、悪い意味で繊細で手が付けられないコード書く作業員ばかり。
OOPやMVCの信望者。辛抱者なのかもだが、それは別として。
フレームワーク採用して書き捨てじゃ意味ないからね。
そんな「じゃぁ『ドレ』」で選ぶに値するフレームワークを、機能や設計ではない「意義」の段階から訊いて見たかった。
0223nobodyさん
2007/12/19(水) 04:04:26ID:???考え方が二つに分かれるという前提を語れてなかったので捕捉。
a:
FW採用によって簡略化でき、スタッフ相互の記述の整合性を保ちやすくなる
b:
FW採用によって簡略化できる代わりに、適用の手間と、学習コスト、サーバ要求、依存関係が発生する
a:、b;、どっちがいいかって話で、その水準は無いなと悩んで、
後者に傾いていたのが>>204,205を書き込んだ精神状態。
なんか煽り口調が反響招いてしまいました。
これもフレームワークの意義を問いたかった故なのです。ご容赦下さい。
もちろん嘘は言ってないので反論ください。
でも明日昼出社なので今は寝ます済みませんおやすみなさい。
0224209
2007/12/19(水) 06:21:18ID:???> そんな「じゃぁ『ドレ』」で選ぶに値するフレームワークを、機能や設計ではない「意義」の段階から訊いて見たかった。
今後ずーっと使い続けられるもの :-)
で、俺俺脱却「もう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:???0234nobodyさん
2007/12/19(水) 20:24:20ID:???今時の三歳児ってゆとり以下だな
0235nobodyさん
2007/12/20(木) 01:46:50ID:???単に役割ごとにクラスに分けてるだけで。もともとMVCはGUIのアプリを作るときに適用する概念。
PHPの場合はパッケージの仕組みがなくて、ソースが混乱しがちなので、大規模になってきたら役割をクラスで分けるというのは整理できていい方法だと思う。
が、それをオブジェクト指向と呼ぶのは強烈な違和感がある。
0236nobodyさん
2007/12/20(木) 02:00:32ID:???5.3ではサポートされるんだよね？
0237nobodyさん
2007/12/20(木) 03:56:57ID:???切り捨て過ぎじゃね？
ページ遷移伴って破棄される齟齬を埋めるために、永続化関係が語り尽くされた上で今がある訳だしさ。
WOやらStrutsやらがそれぞれのポリシーで上手くやって来た上でRoRとか出て来てるの見ると、オブジェクト指向云々って話じゃなくなってる感じもするな。
如何にlazyに手軽にサブセットDSLやれるかっていう、LL系で実行効率無視したシロモノが好評な時代だし。
結局みんなMVCやりたいのでもOOPやりたいのでもなく、DRYやりたいだけなんじゃないかな。webアプリではなおさら顕著な点だと思う。
クラスを「メソッドとデータをまとめたもの」という切り口だけで扱ってる／しばしば扱わざるを得ない、という状況になると（それが頻繁すぎるんだけど）もうOOPもOOADやらも意味なくなっちまう。
ページ遷移モデルだと、カプセル化使い回しも意義を損ねるし。ポリモルとかPHP自体がそこまで動的に設計できるモンじゃねえし。
そもそも毎ページで色々newされる動きにOOPってマッチしてないかも。
純htmlからJavaScript経由でサーバにアクセスして、永続的オブジェクトにアクセスするサーバサイドスクリプトが走るって動きならまだ納得行くかも。
MVCとか言う前に、クライアント側の設計／サーバサイドの設計をどう見つめ直すかが勝負じゃねえのかな。
0239nobodyさん
2007/12/20(木) 13:50:29ID:???オブジェクト指向と相性良くしようと思えば、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:???ゲームやソフトウェアの開発ってオフラインのイメージが強くてどうも関心が持てない。
誰かのためというよりは、自分のためにシコシコ組んでる感じ。どうでもいいけどさ。
0244nobodyさん
2007/12/20(木) 17:46:49ID:???> ウェブアプリって、データの保存がRDBMS、出力先がHTML。この2つともまったくオブジェクト指向じゃないんだよな。
出力先がオブジェクト指向なものってなに？
（CUIを含めた）ユーザーインターフェースを持たないプログラム？
0245nobodyさん
2007/12/20(木) 17:49:57ID:???> オブジェクト指向と相性良くしようと思えば、RDBMSじゃなくってOODBにするとか、HTMLを全部DOMで操作するとかにしないといけない。
うん。だから今のモダンなウェブアプリ開発では、
オブジェクト指向でデータを読み書きできるO/Rマッパーと
HTMLを作成してくれるオブジェクト指向ライブラリを使うのが当たり前。
0246nobodyさん
2007/12/20(木) 18:57:15ID:???ってのがどういうものか今ひとつイメージできない俺。
当たり前、なのか？
まさか全部DOMでノードノードで組み立てるようなもんじゃ無かろうな。
XMLの悪夢再び？
0247nobodyさん
2007/12/20(木) 18:59:50ID:???その利便性が評価されてるだけで
オブジェクト指向でデータ読み書きって意味不明
OODBって昔から言葉だけ一人歩きしてるしな
実用性あるOODB作るのが難しいとか聞くし
HTML生成も、直書きなテンプレートエンジンばかりだよな
一からDOM組み上げる物view設計って見た事無いぞ
0248nobodyさん
2007/12/20(木) 19:07:21ID:???でもXML/XSLTも構造に対するテンプレートに過ぎないよな。
DOM中のイベントに対してもOO言語側のメソッドとブリッジするくらいじゃないと怪しいかも。
0249nobodyさん
2007/12/20(木) 19:17:32ID:???そのイベントのブリッジ？は全ての場面で気軽に使うのは現実的でない、ていうAjaxの教訓もあってだな。
一回マウスが「オブジェクト」の上をかすめるだけで何十Kmもパケットが行き来してApacheがアクセスログ
吐いてPHPのオブジェクトを一からnewしてDB接続を作成してって・・・どれだけリッチなんだｗ
UI全部JavaScriptもしくはFlashで作るような形になってしまえってことなのか。結局は
0250nobodyさん
2007/12/20(木) 19:33:23ID:???規模によるよ。プレステとかコンシューマー系で1年以上かかって作るゲームのがよっぽど大変。
そっちからウェブに来たけどはっきりって楽勝。ママゴトプログラミング。
0251nobodyさん
2007/12/20(木) 19:34:03ID:???OODBだとかDOMだとか、もうね、極論過ぎだろ
webプログラミングしたことないアホしかいないのかここは
最低限OOPの理解とFW使ってwebプログラムしてる奴か
これからしようとしてる奴くらいにしてくれよ
正直読むに耐えない
■ このスレッドは過去ログ倉庫に格納されています