PHPでOOP (894ﾚｽ)
PHPでOOP http://medaka.5ch.io/test/read.cgi/php/1172205352/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
601: nobodyさん [sage] 2008/12/16(火) 11:17:25 ID:??? はい？批判ってどれ？ http://medaka.5ch.io/test/read.cgi/php/1172205352/601
602: nobodyさん [age] 2008/12/16(火) 12:52:53 ID:??? >>601 批判している書込みは>>479です。 「に」のサンプルが、（コーディングにかかわるルール以外で） MVCの設計はこれで良いのかがあいまいなまま終わってる気がします。 http://medaka.5ch.io/test/read.cgi/php/1172205352/602
603: nobodyさん [sage] 2008/12/16(火) 13:03:16 ID:??? 気になってる批判は>>469もだな。そして>>471となっているが、そのレスが 無くておわってないかい？ http://medaka.5ch.io/test/read.cgi/php/1172205352/603
604: nobodyさん [sage] 2008/12/16(火) 19:38:24 ID:??? よくわかんないんだけど、OOPとMVCって両立できるの？ http://medaka.5ch.io/test/read.cgi/php/1172205352/604
605: nobodyさん [sage] 2008/12/16(火) 19:50:24 ID:??? MVCをOOPで実現するんだろｗ http://medaka.5ch.io/test/read.cgi/php/1172205352/605
606: nobodyさん [sage] 2008/12/17(水) 01:23:14 ID:??? これどうなの？ ttp://www13.plala.or.jp/naka_jima/php/chapter12.html http://medaka.5ch.io/test/read.cgi/php/1172205352/606
607: nobodyさん [sage] 2008/12/17(水) 01:36:07 ID:??? どうって何が？ http://medaka.5ch.io/test/read.cgi/php/1172205352/607
608: nobodyさん [sage] 2008/12/17(水) 03:42:22 ID:??? MVCだと必ずフレームワークを使わなければならないわけでもないよね。ちがうの？ それとも、非常に単純なクラス構成でMVCを実現しようという考えが間違いとか？ http://medaka.5ch.io/test/read.cgi/php/1172205352/608
609: nobodyさん [sage] 2008/12/17(水) 04:51:02 ID:??? 別にいいんじゃ？ http://medaka.5ch.io/test/read.cgi/php/1172205352/609
610: nobodyさん [sage] 2008/12/17(水) 10:09:45 ID:??? >>606見たんだけど、MVCってこんななの？ View や Model 1つに対して1ファイルみたいだけど、ファイル量半端ないことになりそう。 http://medaka.5ch.io/test/read.cgi/php/1172205352/610
611: nobodyさん [sage] 2008/12/17(水) 14:15:45 ID:??? DBの形式や最終的な見せ方によって、ファイル数は変わるんじゃないの？ でも、MVCってわりとファイル多めだよな！ 1ファイルのコード量、大して多くないけど http://medaka.5ch.io/test/read.cgi/php/1172205352/611
612: nobodyさん [sage] 2008/12/17(水) 15:06:27 ID:??? ファイルが多めなのが嫌なら１ファイル内に複数書けばいいじゃない http://medaka.5ch.io/test/read.cgi/php/1172205352/612
613: nobodyさん [sage] 2008/12/17(水) 17:53:39 ID:??? OOPそのものをやろうとするとクラスやファイル量が多くなるからね。 汎用性を考えて作ろうとするとなおさらだ。それはしかたがないのかも。 そこをあえて、フレームワークや外部のモジュールなどを使わずに 非常にクラス数を少なくしてやってみたいなと思うんだけどね。 MVCの理解の一環として。 http://medaka.5ch.io/test/read.cgi/php/1172205352/613
614: nobodyさん [sage] 2008/12/17(水) 20:20:24 ID:??? やってみればいいのでは？ http://medaka.5ch.io/test/read.cgi/php/1172205352/614
615: nobodyさん [sage] 2008/12/18(木) 01:34:16 ID:??? <?php class Framework{ // コントローラー public function controller(array $inp){ $model = $this->model($this->di('Action', $this->di('Action_Mapper',$inp)); $this->view($model); } // モデル protected function model(Action $actions){ return $action->do(); } // ビュー protected function view($model){ print ($this->di('View_Helper', array($model)); } // DIコンテナ protected function di($class, $options){ return new $class($options); } } class HelloWorld extends Frameworkd{} App::controller($_GET); http://medaka.5ch.io/test/read.cgi/php/1172205352/615
616: nobodyさん [sage] 2008/12/18(木) 01:36:48 ID:??? なんじゃそりゃ http://medaka.5ch.io/test/read.cgi/php/1172205352/616
617: nobodyさん [sage] 2008/12/18(木) 01:37:24 ID:??? 最後の一行間違い http://medaka.5ch.io/test/read.cgi/php/1172205352/617
618: nobodyさん [sage] 2008/12/18(木) 08:21:41 ID:??? せめてクラスは３つ以上にするべきだろ。 最低限といっても、ファイルを読み込んで表示とか、書き込みとかの処理まで 出来る機能を持ったほうがコントローラとビューの違いが明確に分かりやすく なると思うんだけど。 http://medaka.5ch.io/test/read.cgi/php/1172205352/618
619: nobodyさん [sage] 2008/12/18(木) 10:48:40 ID:??? これはMVCどこがやるのが妥当か？ ってところで迷う。 時々、曖昧なのが出てきちゃう。 http://medaka.5ch.io/test/read.cgi/php/1172205352/619
620: nobodyさん [sage] 2008/12/18(木) 11:48:41 ID:??? >>619 ここで事例を通じて具体的な意見を交わしていけばどうかな？」 例えば・・・ 掲示板 ■コントローラ：処理の内容を判断するクラス ・プログラムが実行された時、一番最初に実行される ・POSTの値をみて、以下の処理にてどれに該当するかを判断する ・データを表示する ・データを書込む ・編集用のフォームを表示する ■ビュー：htmlのレイアウト表示を担当するクラス ・以下のメソッドを持つ ・データをhtmlで表示する ・データ編集用htmlを表記する ■モデル：データファイルを管理するクラス ・ファイルの読み込み、書込みをする ・外部とは１件分のデータはBBSLineクラスでやりとりする http://medaka.5ch.io/test/read.cgi/php/1172205352/620
621: nobodyさん [sage] 2008/12/18(木) 12:24:15 ID:??? >>620 『■コントローラ：処理の内容を判断するクラス 』の > ・データを表示する > ・データを書込む 『 ■モデル：データファイルを管理するクラス 』の > ・ファイルの読み込み、書込みをする って、意味が重複しているような感じがするのですが... ならば、 ■コントローラ：処理の内容を判断するクラス ・モデルからデータを受け取る ・モデルにデータを渡す とかでは、おかしいですか？ http://medaka.5ch.io/test/read.cgi/php/1172205352/621
622: nobodyさん [sage] 2008/12/18(木) 12:52:00 ID:??? >>621 >>620じゃないけど。 ・データを表示する ・データを書込む ・編集用のフォームを表示する 実際に上記の作業をするのは View と Model だよ。Controllerがするわけじゃない。 コントローラーはどれがリクエストされたかを判断して、適切な Model と View を呼び出す。 http://medaka.5ch.io/test/read.cgi/php/1172205352/622
623: nobodyさん [sage] 2008/12/18(木) 16:39:54 ID:??? >>469は具体的に何処のコードを批判しているのかが分からないので どなたか解説を頼みます。 http://medaka.5ch.io/test/read.cgi/php/1172205352/623
624: nobodyさん [sage] 2008/12/18(木) 20:10:31 ID:??? MVCモデルでM同士で連携することってあり？ それとも必ずC経由？ C経由の場合、Mをなるべく疎結合になるように細分化してると、 Cの各Actionに書くロジック量が半端なく多くなってくるんだよね。 （Aデータを取ってきてBデータを取ってきてBをCバリデータに通してAとBを基にDを作成して・・・みたいな） 一つのAction内にロジックが増えるのもどうかと思うし、それって新しいモデルじゃんという気もしてこないでもない。 http://medaka.5ch.io/test/read.cgi/php/1172205352/624
625: nobodyさん [sage] 2008/12/18(木) 20:23:33 ID:??? >>624 俺はM同士で連携するかたちでも良いと思うけどね。 CからMを見た場合、あるまとまった処理単位でメソッドを呼び出す形であることが 重要だと思うから。 CがMを使うときは必ずメソッドＡ呼び出してメソッドＢ、メソッドＣを実行しなければならない。 さらに、そういう３連呼び出しがCの中に何箇所か書かれているなんていうのは再利用性などが 悪くなると思うから。 http://medaka.5ch.io/test/read.cgi/php/1172205352/625
626: nobodyさん [sage] 2008/12/19(金) 16:35:55 ID:??? 試しに掲示板をMVCでやったら、なんかやっとそれっぽくなった。 http://medaka.5ch.io/test/read.cgi/php/1172205352/626
627: nobodyさん [sage] 2008/12/19(金) 19:23:16 ID:??? >>626 うｐきぼん http://medaka.5ch.io/test/read.cgi/php/1172205352/627
628: nobodyさん [sage] 2008/12/20(土) 14:28:47 ID:??? >624 変化する内部状態を持つモデル同士で連携させると見通しが悪くなる。 生成してから、（観察される）内部状態が変化しないようなモデルはどこから呼んでもそれほど大きな問題はない。 オブジェクトの生成期間中に（観察される）内部状態が変化するようなモデルは、C直轄にしといた方がいい。 http://medaka.5ch.io/test/read.cgi/php/1172205352/628
629: nobodyさん [sage] 2008/12/20(土) 14:34:18 ID:??? 生成期間→生存期間 なんか寝ぼけてた。 要は変化する「状態」を持っているもの全てはCの管理下に置いておいた方がいいってこった。 「状態」が無いもの（生成時にファイルからデータをロードしてそれっきり、とか）はどこにあったって構わない。 インスタンスの生成を行なうクラスは自分ルールでもいいからある程度絞っておかないと混乱すると思うけどな。 http://medaka.5ch.io/test/read.cgi/php/1172205352/629
630: nobodyさん [sage] 2008/12/20(土) 15:34:43 ID:??? 変な質問だけど、OOP での Validator ってのがよくわかんねえ。 is_numeric(); とかをModel内にべた書きしないで、Validatorオブジェクトを通じて、変数の内容を確認すればいいの？ $str = 'string'; $valid =& new Validator(); $valid->isStr($string); みたいな感じで。 BaseValidator みたいな基本的なチェックをするクラスを作って、継承した先で複雑なチェック用のメソッドを実装させればいいのかな。 http://medaka.5ch.io/test/read.cgi/php/1172205352/630
631: 630 [sage] 2008/12/20(土) 15:37:54 ID:??? 引数間違えてる。最後の行。 $valid->isStr($str); ね。まぁ、別に問題ないが。 http://medaka.5ch.io/test/read.cgi/php/1172205352/631
632: nobodyさん [sage] 2008/12/20(土) 15:54:47 ID:??? 問題はありまくりだろ http://medaka.5ch.io/test/read.cgi/php/1172205352/632
633: nobodyさん [sage] 2008/12/20(土) 16:42:14 ID:??? >630 ttp://gist.github.com/38261 俺はValidatorクラスはコントローラ単位で実装してる。「入力値の検証」なのだから、コントローラの責任。 Validatorだけ独立させるのはコードの見通しを良くするためであり、責任はあくまでコントローラにある。 ただ、実際にそっからコールするのはModelのメソッド。何が許可されるかを知ってるのはだいたいModelだからな。 たとえば受け付ける値が日付なら、そっから日付クラスのvalidateメソッドを呼び出す（MyDate::validate($string)）。 POSTされる中に列挙型（<select>から送られるような、選択肢が限られているもの）とかがあった場合にこの構成は滅茶苦茶強い。 <select>のためのデータ生成とか、送られたvalueから画面表示用の文字列（「〜モード」とか）への変換を一箇所に集められる。 あと、文字列が決まったフォーマットになっているか調べる場合とかな。 is_strとかctype_stringとかstrlenだけで検証が終わるものはvalidatorクラス内に直書きする。 validateNumericとかvalidateStrとか書くよりその方が分かりやすい。 http://medaka.5ch.io/test/read.cgi/php/1172205352/633
634: nobodyさん [sage] 2008/12/20(土) 17:07:58 ID:??? >>633 ものすごく丁寧にありがとう。 まだぼんやりとしかわからないけど、サンプルコードを読み解いて、いろいろ試してみる。 http://medaka.5ch.io/test/read.cgi/php/1172205352/634
635: nobodyさん [sage] 2008/12/20(土) 17:13:17 ID:??? >>633 >「入力値の検証」なのだから、コントローラの責任。 「検証する」んじゃなく「検証させる」のが仕事じゃないの？ ここでいう入力値の検証って例えばどんなこと言ってる？ 3行目で >何が許可されるかを知ってるのはだいたいModelだからな。 って書いてるってことは、なにか、Modelに関係ないものを想定してると思うんだけど。 http://medaka.5ch.io/test/read.cgi/php/1172205352/635
636: nobodyさん [sage] 2008/12/20(土) 18:07:36 ID:??? >635 大雑把に言うと、処理を始める前に可能なパラメータの検証全般。 純粋に入力値だけを見て判定できるものだな。システムや環境の状態を見なくとも判定できるエラーを出す役割。 処理を始めないと分からないもの（DBに指定されたエントリーがあるかとか）は、バリデーションでは扱わない。 DBにこの値があった場合はクッキーにこれが無いといけない…みたいなのも対象外。 日付として「'9999-12-31'」が指定されてもバリデーションでは引っ掛けない。これは有効な入力。 「'2008-13-45'」はバリデーションでエラーとして引っ掛ける。この日付が有効になる事はあり得ないから。 メールアドレスが正しいフォーマットかをチェックするのはバリデーションで、それが有効なメールアドレスかをチェックするのはモデル。 ユーザーIDとして正しいフォーマットならばバリデーションは通るが、当該ユーザーがいない場合モデルがエラーを出す。 http://medaka.5ch.io/test/read.cgi/php/1172205352/636
637: nobodyさん [sage] 2008/12/21(日) 00:53:43 ID:??? >>636 なんとなく分かるけど、 例えばそれだと「2008-13-45は日付(のつもり)」ってことを コントローラが知っとかないといけないってことだよね？ あと、日付が必要なくなった、とかいうときは コントローラーを変更しないといけないってことにならない？ なんか拘ってるようでアレだけどお勉強スレってことで許してｗ http://medaka.5ch.io/test/read.cgi/php/1172205352/637
638: nobodyさん [sage] 2008/12/21(日) 00:57:41 ID:??? って、もしかして、リクエストとして渡ってくるものを想定してるのかな。 hoge.php?date=20081231 とか。 http://medaka.5ch.io/test/read.cgi/php/1172205352/638
639: nobodyさん [sage] 2008/12/21(日) 12:32:43 ID:??? >637 「コントローラ」の指している範囲が俺と違う気がする。 俺はディスパッチャ（処理の振り分け）部分じゃなくて、そこから振り分けられる先のコントローラを指している。 ぐぐったが、「アクション」としてクラスにして丸ごとコントローラから切り離す文化圏もあるようだな。 「日付のつもりで送られてくる文字列がある」という事実は、ディスパッチャは（たいていの場合）知らない。 が、コントローラ（アクション）は知っている。だって知らないと日付具象モデルに処理を引き渡しようがないからな。 Cにはどの道変更が入る。リクエストをモデルに引き渡すのが仕事だからな。 「日付がどこからどう渡ってくるか」はCの管轄であってMじゃない。Mはそれを知っていてはいけない。 Mは「日付を渡されたらどうする」だけ知っていればよく、実際問題どこに日付があるかはCが隠蔽すべき。 たとえば、日付指定でDBからレコードを取っていたのを、「無指定時は今日と見なす」と変更したとする。 この場合は、Cを「日付省略時は現在の日付でMを呼び出す」ように変更し、Mには触れないのが正しい。 「省略時は日付を無視して過去のレコードを全取得する」という場合は、データ取得ロジックが変更なのでまずMは変わる。 制御の構造、呼び出しインターフェイスも変わるのでCも変わる。 http://medaka.5ch.io/test/read.cgi/php/1172205352/639
640: nobodyさん [sage] 2008/12/21(日) 12:37:44 ID:??? まあ実際は、日付省略時のMの挙動を変えるだろうけどな。 >638 入力値以外のもの（DB内の値とか処理結果）の検証は当然モデル。 というか、そういうのは一般にはバリデーションとは言わずアサーションと呼ぶ。 http://medaka.5ch.io/test/read.cgi/php/1172205352/640
641: nobodyさん [sage] 2008/12/21(日) 13:45:12 ID:??? >>639 Cは振り分けだけが仕事だと思ってたんだけど。 その先にさらに C があることなんてあるのか。 サブコントローラーみたいな感じ？ http://medaka.5ch.io/test/read.cgi/php/1172205352/641
642: nobodyさん [sage] 2008/12/21(日) 14:51:26 ID:??? >641 やっぱ、そこか。 例えばブログの場合、エントリー群を司るモデルや、タグクラウドを司るモデルができる。これは自明だな。 で、データを受け取って画面を表示するだけの、ごく単純なビューがいる。これも自明。 で、それら呼び出してページのデータを作る、という「データの統合」を司るクラスが必要になる。 これをMVCのうち、MとCのどっちに置くかの問題。 MVC、MVCって言ってるけど、本質的には4層なんだよ。 処理の振り分けに1層を割くならば、4層なくてはならない。 処理の振り分け=呼び出すCの決定（ディスパッチャ）→どのMを呼び出すかを制御する（コントロール） →データを実際に扱う（モデル）→表示（ビュー）、となる。 実際のフレームワークだと、RailsやZendはDispatcherが振り分けを担当し、制御はコントローラが執っている。 （だから、おまいの目から見れば、コントローラは仕事をやりすぎに見えるはず） SymfonyやCakeだとControllerがディスパッチを担当し、制御はActionが執っている。 CodeIgniterだとディスパッチは単一のエントリポイント（リクエストを受けるphpファイル）であるindex.phpが行なって、制御はCが行なっている。 http://medaka.5ch.io/test/read.cgi/php/1172205352/642
643: nobodyさん [sage] 2008/12/21(日) 15:35:51 ID:??? >>642 >たとえば、日付指定でDBからレコードを取っていたのを、「無指定時は今日と見なす」と変更したとする。 >この場合は、Cを「日付省略時は現在の日付でMを呼び出す」ように変更し、Mには触れないのが正しい。 これって制御じゃなくてロジックだからモデル的仕事じゃねぇの？ http://medaka.5ch.io/test/read.cgi/php/1172205352/643
644: nobodyさん [sage] 2008/12/21(日) 16:01:38 ID:??? >>642 横槍で質問してすまんかった。 すげーわかりやすい。 勉強になった。ありがとう。 http://medaka.5ch.io/test/read.cgi/php/1172205352/644
645: nobodyさん [sage] 2008/12/21(日) 16:03:24 ID:??? 4層ｗｗｗ http://medaka.5ch.io/test/read.cgi/php/1172205352/645
646: nobodyさん [sage] 2008/12/23(火) 01:41:15 ID:??? >>645 あなたの顔に死相が出ていますよ。4層だけに。 http://medaka.5ch.io/test/read.cgi/php/1172205352/646
647: nobodyさん [sage] 2008/12/24(水) 12:54:19 ID:??? 考え方としてディスパッチとコントロールは分けるべきだが、 実装するときは、コントロールで括るよな？ http://medaka.5ch.io/test/read.cgi/php/1172205352/647
648: 642 [sage] 2008/12/24(水) 22:47:37 ID:??? >647 M・V・Cで分けるならCってのは同意。いちおう > 処理の振り分けに1層を割くならば と予防線は張ってあるわけだが。 俺はControllerの親クラスとかControllerFactoryでディスパッチする事が多い。 http://medaka.5ch.io/test/read.cgi/php/1172205352/648
649: nobodyさん [sage] 2008/12/25(木) 12:55:55 ID:??? >>648 > Controllerの親クラスとかControllerFactoryでディスパッチする事が多い ディスパッチャーのインターフェースを作って、コントローラクラスでインプリメンツするってのは駄目なの？ http://medaka.5ch.io/test/read.cgi/php/1172205352/649
650: nobodyさん [sage] 2009/01/04(日) 21:25:44 ID:??? 保守 http://medaka.5ch.io/test/read.cgi/php/1172205352/650
651: nobodyさん [sage] 2009/01/10(土) 18:38:23 ID:??? 保守 http://medaka.5ch.io/test/read.cgi/php/1172205352/651
652: nobodyさん [sage] 2009/01/18(日) 01:35:36 ID:??? 手始めに、サイトのリニューアルついでにSmarty入れてCMS'っぽく'してみる。 http://medaka.5ch.io/test/read.cgi/php/1172205352/652
653: nobodyさん [sage] 2009/01/26(月) 20:14:56 ID:??? お？サンプルか？ http://medaka.5ch.io/test/read.cgi/php/1172205352/653
654: nobodyさん [] 2009/02/02(月) 14:37:18 ID:JcAer1H1 勉強すればするだけフレームワーク使えば手っ取り早いことがわかった。 自作のモチベ下がっちまったい。 http://medaka.5ch.io/test/read.cgi/php/1172205352/654
655: nobodyさん [sage] 2009/02/02(月) 14:46:20 ID:??? 自作する理由は楽するためじゃないだろう http://medaka.5ch.io/test/read.cgi/php/1172205352/655
656: nobodyさん [sage] 2009/02/02(月) 14:54:00 ID:??? もっと手っ取り早く使えるフレームワークをつくるために勉強すればいい http://medaka.5ch.io/test/read.cgi/php/1172205352/656
657: nobodyさん [sage] 2009/02/02(月) 15:06:11 ID:??? 元々目的としては自サイトで使うための軽量フレームワークを作るために勉強してたの。 で、既存のフレームワークのマニュアルとかソースを参考にしながら作ってたんだけど、取り込むつもりが逆に呑まれた形。 http://medaka.5ch.io/test/read.cgi/php/1172205352/657
658: nobodyさん [sage] 2009/02/02(月) 20:06:44 ID:??? 凄く難解なソースを引き継ぎさせられて、途方にくれかかった。 で、市販のモジュールを使うなどして０から作り直すなどの方法を 模索したが、結局は引継ぎしたソースを解読して手を加えるのが 楽で、早い道であることが分かった。みたいな話かな？ｗ PHPではないが、俺はちょうどこんな感じの体験をしたことがあるｗ http://medaka.5ch.io/test/read.cgi/php/1172205352/658
659: nobodyさん [sage] 2009/02/03(火) 00:06:52 ID:??? まぁ、たぶんそんな感じ。 要するにフレームワークの魅力に気付いたわけですよ。 http://medaka.5ch.io/test/read.cgi/php/1172205352/659
660: nobodyさん [sage] 2009/02/03(火) 01:52:40 ID:??? 先に気づいてからやれば良かったな http://medaka.5ch.io/test/read.cgi/php/1172205352/660
661: nobodyさん [sage] 2009/02/04(水) 08:03:26 ID:??? そういうのは簡単に気づけないだろう。 プログラムは体感して分かっていくものなのだから。 http://medaka.5ch.io/test/read.cgi/php/1172205352/661
662: nobodyさん [sage] 2009/02/04(水) 21:38:41 ID:??? 俺としては魅力に気付けただけでも大きな進歩だ。 自作云々は別にして。 http://medaka.5ch.io/test/read.cgi/php/1172205352/662
663: nobodyさん [] 2009/02/05(木) 22:29:31 ID:6GWaaOT6 あけおめ http://medaka.5ch.io/test/read.cgi/php/1172205352/663
664: nobodyさん [sage] 2009/02/06(金) 07:54:15 ID:??? では、その気づいた魅力的な部分をここなどで紹介してみるというのはどうよ？ PHPでOOPのスレの趣旨に添ってると思うし、他の人の意見を聞いて 参考になる部分もあると思うのだが。 http://medaka.5ch.io/test/read.cgi/php/1172205352/664
665: nobodyさん [sage] 2009/02/07(土) 01:12:17 ID:??? >>4 宣伝乙 http://medaka.5ch.io/test/read.cgi/php/1172205352/665
666: nobodyさん [age] 2009/02/09(月) 20:26:45 ID:??? えらく昔の書き込みにレスしてるな。 http://medaka.5ch.io/test/read.cgi/php/1172205352/666
667: nobodyさん [age] 2009/02/12(木) 07:33:22 ID:??? フレームワークの魅力についてまとめてみるか？ http://medaka.5ch.io/test/read.cgi/php/1172205352/667
668: nobodyさん [sage] 2009/02/12(木) 09:08:20 ID:??? どうぞ http://medaka.5ch.io/test/read.cgi/php/1172205352/668
669: nobodyさん [sage] 2009/02/12(木) 15:59:22 ID:??? >>667 wikiにしてもらえるなら俺も手伝う http://medaka.5ch.io/test/read.cgi/php/1172205352/669
670: nobodyさん [age] 2009/02/12(木) 20:11:52 ID:??? いや、俺はそんなに文章がかけるほど知識は無い。申し訳ないが、サポートに回る http://medaka.5ch.io/test/read.cgi/php/1172205352/670
671: nobodyさん [sage] 2009/02/12(木) 20:25:45 ID:??? なぜにフレームワークの魅力をまとめようと？ http://medaka.5ch.io/test/read.cgi/php/1172205352/671
672: 662 [sage] 2009/02/12(木) 20:56:21 ID:??? >>662 ≠ >>667 だからね。 俺は人に語れるほどまだ理解してないから。 http://medaka.5ch.io/test/read.cgi/php/1172205352/672
673: nobodyさん [sage] 2009/02/12(木) 20:59:58 ID:??? なんだ教えて君か http://medaka.5ch.io/test/read.cgi/php/1172205352/673
674: nobodyさん [age] 2009/02/12(木) 21:37:52 ID:??? おまえもな http://medaka.5ch.io/test/read.cgi/php/1172205352/674
675: nobodyさん [sage] 2009/02/12(木) 22:00:11 ID:??? サポートするといってるんだから、教えてじゃないだろｗ http://medaka.5ch.io/test/read.cgi/php/1172205352/675
676: nobodyさん [sage] 2009/02/13(金) 20:54:05 ID:??? ttp://q.hatena.ne.jp/1188498291 http://medaka.5ch.io/test/read.cgi/php/1172205352/676
677: nobodyさん [sage] 2009/02/15(日) 23:40:26 ID:??? >>676を読んでみて、PHPに限らず、ASP.NETを体感してみると、フレームワークの メリットやデメリットがみえてくるんじゃなかと感じた。 あれは、ポストバックとか独自の理論があって、それを学ばないと使えるようになれない。 しかし、ページをまたがってデータの受け渡しをする際は、非常に便利な機能であり、 使いこなせるようになると、生産性が向上する。 http://medaka.5ch.io/test/read.cgi/php/1172205352/677
678: nobodyさん [sage] 2009/02/16(月) 00:05:47 ID:??? 一問一答形式でwikiでも作るか http://medaka.5ch.io/test/read.cgi/php/1172205352/678
679: nobodyさん [sage] 2009/02/16(月) 00:44:15 ID:??? visualstudioが優秀すぐる http://medaka.5ch.io/test/read.cgi/php/1172205352/679
680: nobodyさん [] 2009/02/16(月) 11:09:32 ID:IOY0ae9e Java とか C#やったほうが飲み込みは早くなるのかな。 でも両者とも動かせるサーバって高いからなぁ。 Web以外にも用途はあるけど。 http://medaka.5ch.io/test/read.cgi/php/1172205352/680
681: nobodyさん [sage] 2009/02/16(月) 19:31:23 ID:??? >>680 いろいろな言語に触れてみると、その分視野は広くなることだろう。 共通して実装している機能を見ることで、OOPの概念をつかんだり 出来るはずだし。 しかし、広く浅くにとどまっていると、何も作れないで終わるので、 物を作る際は、一つの言語に絞り込んでいた方が良い。 なので、java や C# においてはローカルで稼動させるのにとどまらせて おいたらどうかな？ASP.NET だと、Webアプリでもローカルでテスト動作 させる環境が Express にもついてるし。 http://medaka.5ch.io/test/read.cgi/php/1172205352/681
682: nobodyさん [sage] 2009/02/16(月) 23:33:26 ID:??? ウェブアプリの範囲なら、どの言語のどのフレームワークでも大差ないよ。 ASP.NETは、デスクトップアプリケーションからのアプローチなんで、これだけちょっと勝手が違うけど。 プログラミングを仕事にするなら、最初は型ありの言語をやった方がいいと思う。 JavaとかC#が理解出来れば、PHPやPerlはすぐに分かる。 http://medaka.5ch.io/test/read.cgi/php/1172205352/682
683: nobodyさん [sage] 2009/02/17(火) 12:38:03 ID:??? でも、perlってすぐ忘れちゃうよな... http://medaka.5ch.io/test/read.cgi/php/1172205352/683
684: nobodyさん [sage] 2009/02/17(火) 20:53:57 ID:??? >>683 それはそれで良いのではないかと思っている。 perlのモットーがあわないのであれば、PHPを使うで良いと思うし。 http://medaka.5ch.io/test/read.cgi/php/1172205352/684
685: nobodyさん [age] 2009/02/23(月) 20:40:12 ID:??? PHP では OOP を学べないという意見があるが、結論だけ いうのではなく、その理由の部分を述べていくといいかもね。 http://medaka.5ch.io/test/read.cgi/php/1172205352/685
686: nobodyさん [sage] 2009/02/23(月) 21:35:23 ID:??? 別に学べるのでは？ http://medaka.5ch.io/test/read.cgi/php/1172205352/686
687: nobodyさん [sage] 2009/02/23(月) 22:27:49 ID:??? ん、どこかにPHPでは学べないと書いてあるのかな？ 個人的には、純粋にOOPを学びたいのであれば別の言語がいいかなーとは思う。 理由は、Webは身近だし使い慣れてると言えるかもしれないが PHP以外のHTMLやらJSやらHTTPプロトコル等知らなければいけない知識が多くあるから。 その辺を知っていれば問題はないと思うけどね。 http://medaka.5ch.io/test/read.cgi/php/1172205352/687
688: nobodyさん [sage] 2009/02/23(月) 23:55:46 ID:??? オブジェクト指向を本格的に勉強したければ、GUIのプログラムを書いた方がいい。ウェブアプリじゃオブジェクト指向が出る幕はない。 http://medaka.5ch.io/test/read.cgi/php/1172205352/688
689: nobodyさん [sage] 2009/02/24(火) 02:09:17 ID:??? 出る幕はあると思うが、最終的にフレームワークを構築することになると思う。 いきなりWEBフレームワークを作ることは難しいので、 実際に存在するフレームワークのソースを追いかけ、参考にしながら、 オレ的フレームワークを組み上げることで、様々な知見を得ることができると思う。 また、これらのフレームワークはたいてい、何らかのデザインパターンやアークテクチャパターンが使われているため、併せてこれらも学習する必要があると思う。 http://medaka.5ch.io/test/read.cgi/php/1172205352/689
690: nobodyさん [sage] 2009/02/24(火) 12:23:13 ID:??? WEBアプリでもActionScript3なら、バリバリOOPだYO! http://medaka.5ch.io/test/read.cgi/php/1172205352/690
691: nobodyさん [sage] 2009/02/24(火) 12:40:12 ID:??? まあ、いつかはサーバサイドはAPIを提供するだけで、クライアントのUIはFlashとかJavaScriptに任せるような時代がくるのかも。 http://medaka.5ch.io/test/read.cgi/php/1172205352/691
692: nobodyさん [sage] 2009/02/24(火) 19:41:39 ID:??? >>691 エンタープライズならそんなケースいくらでもあるだろｗ http://medaka.5ch.io/test/read.cgi/php/1172205352/692
693: nobodyさん [sage] 2009/02/24(火) 20:31:42 ID:??? >>689 俺的フレームワークなんて作らないほうがいい。 自己主張ばかり強い勘違いになりがちだし、遠回り。 良い先人の手本を眺めるほうがよっぽど効率的だわ。 http://medaka.5ch.io/test/read.cgi/php/1172205352/693
694: nobodyさん [sage] 2009/02/24(火) 20:35:16 ID:??? >>693 ホントにそうだとしたらとっくに淘汰されて現状のフレームワークの乱立状態にはならないと思うが http://medaka.5ch.io/test/read.cgi/php/1172205352/694
695: nobodyさん [sage] 2009/02/25(水) 06:21:18 ID:??? >>692 聞いたことないな。そんなことするぐらいなら、Windowsアプリケーションなり、Accessなりで直接DBを参照するから。 http://medaka.5ch.io/test/read.cgi/php/1172205352/695
696: nobodyさん [sage] 2009/02/26(木) 22:25:57 ID:??? クライアントマシンの性能がこれだけアップしているのに、 クライアントマシンの性能を利用しないなんて どれだけ無駄なんだかｗ http://medaka.5ch.io/test/read.cgi/php/1172205352/696
697: nobodyさん [sage] 2009/02/26(木) 23:57:14 ID:??? ぶっちゃけサーバサイドのフレームワークは制作の効率のためであって 性能うんぬんは考えてないんだよな http://medaka.5ch.io/test/read.cgi/php/1172205352/697
698: nobodyさん [sage] 2009/02/27(金) 00:54:42 ID:??? 勉強不足で申し訳ないんだが、制作の効率より性能うんぬんを優先したフレームワークを教えて欲しい http://medaka.5ch.io/test/read.cgi/php/1172205352/698
699: nobodyさん [sage] 2009/02/27(金) 05:45:51 ID:??? つーか開発効率は性能に含まれるだろう http://medaka.5ch.io/test/read.cgi/php/1172205352/699
700: nobodyさん [sage] 2009/02/27(金) 06:00:50 ID:??? は？ http://medaka.5ch.io/test/read.cgi/php/1172205352/700
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 194 ﾚｽあります
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.839s*