元スレ【PHP】フレームワークについて語るスレ10【総合】
php覧 / PC版 / みんなの評価 : ○
前へ
51 = :
全部staticなクラスって単なる構造化プログラミングじゃん。
52 = :
>>51
それは言えるかも。オブジェクト指向ではないと。
まあぶっちゃけstaticなプロパティを、globalsのいらないglobal変数として
使ってる私が通りますよ、と。
原則がないといくら文法がJavaに近くなっても意味がないってことはありそう
でもそれはデザインパターンと直接には関係しないような
singletonにしたって、普通にglobalじゃんっていう評価みたいだし。俺はよくわからんけどね
53 = :
オブジェクト指向は単なる表記方法ではなく考え方なので、
全部staticのクラスだろうがオブジェクト指向にすることは可能。
さらにいえば、別にクラスがなくても可能。
スレッドのないPHPではsingletonに色んなざっくばらんな代替方法があると。
ただ汎用的な知識としてはJavaのやり方が無難で
わざわざ他の方法をとることもないということだな。
よくわかった。
54 = :
えらく短絡的なまとめきたー
てかそんな投げやりなまとめなら23とか名乗らず名無しで書けよｗ
ちょっとでも擁護したレスが軒並み後悔するような、嫌な感じだｗｗｗ
さあ寝よ
55 = :
？
別に君に擁護されなくても全く困らんよ？
もともと馬鹿に的外れな批判されても痛くもなんともないし
62 = :
全部staticメソッドにするというなら、それは構造化プログラミングそのものなわけで、それと比較するなら、オブジェクト指向プログラミングだろ。
シングルトンパターンという実装パターンの一つとじゃ比較の対象にならない。
63 = :
構造化プログラミングとOOPを峻別してる奴なんなの？
OOPは構造化プログラミングを含んでるんだよ
書き方の問題ではない
66 = :
構造化プログラミングとオブジェクト指向プログラミングは比較して語られるものだよ。
あるプログラム、ある言語をを見て、それが構造化プログラミングなものなのか、オブジェクト指向プログラミングなのか、区別されるんだから。
その区別が出来ないというのは、人類皆兄弟とかいうたぐいの屁理屈だ。
67 = :
もうお馬鹿ちゃんは書かない方がいいんじゃないか
自分を大きく見せようとする努力ほど無意味なものはない
68 = :
オブジェクト指向プログラミングは、構造化プログラミングを含んでいるものだから、
プログラムを見て、オブジェクト指向プログラミング特有のクラス等を
（正しく）使っていればオブジェクト指向、使っていなければ構造化って判断をするな。
69 :
RUBYはオブジェクト指向を前提とした言語で、PERLは本来構造化言語なのをパッケージをクラスに流用することでオブジェクト指向の機能を持たせている。
昔の8ビットマイコン時代のBASICはGOTO文で処理を行き来する非構造化言語。
このプログラミングのパラダイムシフトは世界の共通認識だから。
70 = :
>>68
「～判断をするな。」が、I do なのか you shouldn't do なのかわからん
>>69
>このプログラミングのパラダイムシフトは世界の共通認識だから。
だから、何なんだ
どうせならもう少し結論を明確にしてもいいんじゃないかと思う
話がふわふわして仕方がないｗ
71 :
はじめまして、質問させてください。
社内でWebサービス構築のために
MVCモデルのPHPフレームワークを作ることになったのですが、
どのあたりまでの実装でフレームワークとして体をなすのか分かりません。
どなたか教えていただけませんでしょうか？
72 = :
それが分からない人達がフレームワークを作ることに意味があるとは思えない
既存のものを使った方がいいのでは？
73 = 71 :
回答ありがとうございます。
私も車輪の発明になる気がしてどうも１００％乗り気になれないのです。
ちなみに72さんは自作フレームワークの作成または、
既存のフレームワークで、ずっと使い続けてるものありますか？
74 = :
>>72
オープンソース全面禁止とかいう規則の会社もあるらしいし、
意味が無いかどうかはわからないのでは？
（PHPやApache自体もオープンソースだから、それはないかもだけどｗ）
>>71
フレームワークを利用する目的って、多分複数案件で使い回す事が出来て、また
複数の開発者で、またある程度の期間にわたって共通認識・理解をもつことで、
開発コストおよび保守コストを抑えることだと思うんだ
後は、基本的な部品を気合い入れて作ることで、品質の最低ライン（主にセキュリティ面など）を
保証するという意味合いもあるけど
だから、どこまでというのは程度問題でしかないと、個人的には思う
やりすぎれば使い回しに自由がきかなくなったりするし、緩すぎれば保守コストの
軽減には役に立たなかったりするんじゃない？
極端に言えばディレクトリ構造を決めて使い回すだけでも、ある意味「フレームワーク」
だと思う
75 = 71 :
>>74
>だから、どこまでというのは程度問題でしかないと、個人的には思う
なるほど、なかなか外部の方との技術意見交換をする機会がなくて参考になります。
ありがとうございます。
実は1ヶ月ほど前に公開になったあるBtoBのWebサービスで
MVCではないですが、自作でフレームワークを作ってみました。
少しは楽できるのですが、ホントに方向性的に合ってるのか、
若干迷いつつあるんです。
上からMVCモデルのフレームワークを準備してくれと頼まれた中で、
また０から準備することが本当に必要なのか迷ってまして。。。
この掲示板でやめた方がいいなと思ったとしても
やらないといけないことには変わりないんですけれど。
76 = :
MVCにこだわるなら
・各データの出し入れの基礎的な記述と、各データごとのロジック
・表示に関する基礎的な記述とロジック
を、実行スクリプトから切り離すのが最低限？
例えば、昔よく見た
<?php
// DB接続処理ほげほげ
（省略）
$sql = 'SELECT * FROM customer;';
$ret = mysql_query($sql, $db);
$rows = array();
while($row = mysql_fetch_assoc($ret)){ $rows[] = $row; }
?>
<html>
（略）
<?php
foreach($rows as $row){
（略）
}
?>
（略）
</html>
なんてのを、どう分けるか、何のために分けるか、というお話だと思うんだ。
その具体的な分け方・方向については・・・うーん俺は人に教えるほど
きちんと勉強していません。頑張れ！（ｵｲ）
77 = 71 :
>>76
ありがとうございます。参考にさせていただきます。
78 = :
>>75
えーとな。
まずフレームワークを使ってから
考えれ。
79 = :
>>75
>>78の言うように
まず既存のフレームワークを利用してみて、長所や短所を理解してから、
自分(とその周り)が使うに当たって必要な構造としてどうなってると使いやすいか考えて
設計しなきゃいけないんでない？
CIスレとかCakeスレで出てる疑問とかそこらのブログで出てるような疑問とかも割りと参考になりそうな気がします。
後、巷ではやってるフレームワークは付属のライブラリが充実してるってのもポイントだったり。
Viewにはテンプレートエンジンを使う必要があるのかとかも考えたり。
>>71がどのように考えてるか分かりませんが、結構重そうな内容ですね。
で、俺もまた、人に教えるほどきちんと勉強していません。頑張れ！(ｵｲ)
80 :
ありがとうございます。
ViewはSmartyの実績があるので、ほぼ確定かと思います。
あとはMCですね。
で、ご指摘の通り、既存のフレームワークをいくつか
実際に使ってみて、超シンプル版から作っていこうと思います。
それにしても結構種類ありますよね～。
81 = :
>>80
とりあえずCakePHPとCodeIgniterは分かりやすいかな。
SinfonyやEthnaも人気あるっぽいけど。
後は、とりあえず有名なフレームワークをそのまま流用して、
自分の作りたい方向性に足りないものを追加/修正してやって、
作っちゃうっていう方向性も検討の余地がありそうです。
82 = :
骨は例えばちいたんでもいいのでは
他のはどうしても、流儀を覚えてそれに則らないと
カスタマイズも難しいような所があるし
ライブラリは、ぶっちゃけPEARやZendを引っ張ってきて、
そのままではごちゃごちゃになるなら、その一部のコードを、
流用して使えば済むことも多い
83 = 80 :
>>81
なるほど、参考になります。ありがとうございます。
CodeIgniterは知りませんでした。勉強になります。
>>82
>流儀を覚えて
そうですよね。そのコストもありますよね。
ライブラリについては私も同感です。
PEARは今でも使ってますし、DBはADODBを使ってます。
84 = :
しかし、PEARやADODBを使えるのにフレームワークは自作しなきゃならん意味が分からんな。
85 = :
勝ち馬に乗れなくてサポートが止まったらどうするんだ、とか、
複雑すぎると兵隊に書かせられないから却下
（自社開発なら開発者が目の前にいるから例外）とか、
その手の腐った理由かもな。
自作FWなんて最初からサポート止まってるも同然なんだけど。
あとあれだ、
FW使った分だけ工数が削減されるがそれじゃ困る、
なんていう理由じゃないか？
86 = :
フレームワーク使うと大幅に工数下がるね。
でも、フレームワークを勉強するためのコストが要るね。
でもさ、そもそも最低限の勉強をしてから実践投入しろと。
フレームワーク＝最低限の勉強だよ。
87 = :
自分の印象では、CodeIgniterは分かりやすくて良かったです。
SymfonyとかCakePHPは、使い方を学習する段階で、面倒くさいな～と思ってしまいました。
辛抱強く性格でないと、じっくり腰をすえてフレームワークの使い方を学ぶ段階が苦痛に感じられますね？
Zend Frameworkも解説本は分かりやすかったです。
ちいたんはチュートリアルが不十分であると感じました。
EthnaやMapleは試してないので分かりません。
「日本向けの携帯サイトを作る」という視点で見た場合、各フレームワークの使いやすいさ、機能はどうでしょうか？
88 :
一般的に、フレームワークでは、
データベースの外部キー制約を設置していた場合、
親テーブルの行を削除したら、
対応する子テーブルの行も削除されるようになっているのでしょうか？
89 = :
>>88
参照整合性制約（外部キー）までチェックしてデータ操作してくれる
モデルを実装しているフレームワークは寡聞にして聞いたことが無い。
有ったら俺も知りたいな。
96 = :
↑予約メソッドをリストアップして回避すればいいじゃん
そんなに無いよ
98 = :
めんどい
99 = :
___set っていうのもありか。
コーディングの自由度の幅や読みやすさを考えるなら、
いっそ予約されたメソッドなんかは
__reserved_method_CONSTRUCT()
くらいやってくれてもなんの問題もないしな
100 = :
->が一番嫌いなんだよな
.がいいよな.のほうがカッコいい
みんなの評価 : ○
php一覧へ類似してるかもしれないスレッド
- 【PHP】フレームワークについて語るスレ10【総合】 (1001) - [100%] - 2008/8/24 19:04 ○
- 【PHP】フレームワークについて語るスレ12【総合】 (994) - [98%] - 2009/3/19 13:46 ○
- 【PHP】フレームワークについて語るスレ13【総合】 (985) - [98%] - 2009/9/23 3:04 ○
- 【PHP】フレームワーク CakePHP 3ホール目【本命】 (1001) - [59%] - 2008/6/19 7:19 ○
- 【PHP】セッションについて語ろう！【PHP】 (829) - [58%] - 2018/6/27 23:16 ○
- 【PHP】フレームワーク CakePHP 6ホール目【v1.2】 (933) - [57%] - 2009/8/19 2:06 ○
- 【PHP】フレームワーク CakePHP 5ホール目【v1.2】 (985) - [57%] - 2009/3/7 4:53 ☆
- 【PHP】フレームワーク CakePHP 7ホール目【v1.2】 (1001) - [57%] - 2010/3/18 1:18 ○
- 【PHP】フレームワーク CakePHP 4ホール目【v1.2】 (1001) - [57%] - 2008/12/19 21:06 ○
トップメニューへ / →のくす牧場書庫について