元スレ【PHP】PHPフレームワーク総合スレ15

php覧

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 / 要望・削除依頼は掲示板へ / 管理情報はtwitterで

952 = :

当たり前だよな

でも、PHPのFW使いの大半はプログラマとして素人だ。
だからPHPerは質が低いと馬鹿にされる。

上でアダプタパターンが云々言ってるアホがいるけど、
中途半端に解った風になったPHPerが一番恐い、糞コード生成マシンになる

traitsとか使い始めたら世界は崩壊する

953 = :

訂正

×でも、PHPのFW使いの大半は
○>>952とその仲間たちはプログラマとして素人だ。

954 = :

誰かと思えばBootstrapスレで暴れてたキチガイじゃねぇか

955 = :

>>954
つまりあなたは両方のスレで暴れているということですね？

956 = :

今度はフレームワークをセマンティックしに来たか

957 = :

なんか他のスレで暴れていた奴が
こっちに逃げてきてるな。

こっち来んな。はげ

958 = :

>>948
俺はフレームワークに躊躇なく依存するよ
普通と言うなら基本的にフレームワークが用意しているベースモデルを継承して
そこにビジネスロジックを書くのが普通なんだけど
RailsでもDjangoでもフルスタックのものは大抵そのスタイルだしね

POJOを持ち出すからそれについても突っ込むけど
Java界隈じゃ継承の代わりにアノテーション使ってるだけでやってる事は変わんないぜ？
結局はそれを解釈するフレームワークに依存してるんだしな

959 = :

継承はベースクラスがないと
クラス単体で使えない。

アノテーションはベースクラスが不要

この点でぜんぜん違うわけだが？

960 = :

> 俺はフレームワークに躊躇なく依存するよ
具体的に、どのフレームワークの
どのクラスに依存するのか書いてみ。

念の為に言っておくが、ロジック、
つまりモデルの話だぞ。

お前のモデルはなんのクラスを継承するのだ？

961 = :

>>958
>>960
ビジネスロジックがFW依存するのは、FWと共に命運を共にするなら有りじゃね？

そもそもベースモデルが存在するFWって何よ？
大抵はモデルという名のORM実装じゃねぇ

962 = :

>>959
クラス単体で動くアプリですかそうですか良かったですね

>>960
ごめん、FWみんながモデルの継承を強要されてるみたいなおかしな書き方をした俺が間違ってる
継承してるのは逆に一部だ
Symfony 2はDoctrineでアノテーション式、
Zend FrameworkもFuelPHPも自前のマッパーやらアダプターを任意で使える

CakePHP 2 :http://api.cakephp.org/2.3/class-Model.html
Rails: ActiveRecord::Base
Django: django.db.models.Model

そもそも確認するけど、俺はビジネスロジックに
データベースへのアクセスも含まれる認識で話してたんだけどあんたは違うのか？
MVCの、モデルの、更にその一部、そこだけ切り取って「はい移植性高い」なんて喜んでる話だったの？
だとしたらやっぱやるだけ無駄だわ

>>961
ORMでもなんでもいいよ
ビジネスロジックがどうのとかモデルはこうあるべきなんて焦点にしてないから
俺の主張はフレームワークが決めた方法に従え、
移植のために小細工なんてせずに使えって事だ

963 = :

>>960
> 念の為に言っておくが、ロジック、
> つまりモデルの話だぞ。
なんでここまで後退してるんだ？

そもそもの話は>>919
> フレームワークが消えそうならば、フレームワーク部分を比較的簡単に取り替えられるように
> 抽象化しておくするべきだ。

であり、それを実現するために、>>925
> ・Adapter パターン
を使えということだった。

「フレームワーク部分を比較的簡単に取り替えられるように」するためには、Modelのみならず、
当然Controller/View部分も対応しておく必要がある。

964 = :

>>962
＞俺の主張はフレームワークが決めた方法に従え、
＞移植のために小細工なんてせずに使えって事だ
そこは同意する。

ただ俺が言いたいのは、
Cake, Rails, Djamgo等、君が挙げているフレームワークはＯＲＭやＤＢ操作クラスを「モデル」と定義しており、
闇雲に従ってしまうのはよろしくないと思う。

時々素人が「このロジックはControllerに書くべきでしょうか？Modelに書くべきでしょうか？」と聞いてくるけど、
FWでモデル＝DB操作クラスと定義されている為、DBを必要としないロジックを書く場合どうするのか無駄に悩んでしまうんだろうね。

これは、DB操作クラスを内包する本来の意味でのモデルを作るのが正解だと思う。
俺はCakeを使う場合 CakeMdodel(DB) ⇔ 俺俺モデル ⇔ CakeController という方法で実装している

965 = :

>>964
> 俺はCakeを使う場合 CakeMdodel(DB) ⇔ 俺俺モデル ⇔ CakeController という方法で実装している

糞実装の見本

966 = :

>>965
お前がモデルを理解していない事だけはわかった
黙ってBakeしてろ

967 = :

>>964
それ、俺俺モデルの内容をCakeModelで実装すればいいだけじゃないの？
分離するとclass loaderとか面倒なことになりそうな気がするが、それを上回るメリットは？

968 = :

俺俺モデルというか、AppModelを継承して、Cakeの枠組み内で実装すればいいんじゃ？

969 = :

つか、CakePHPのModelのありようが気にくわないならCakePHP使うなって話だな

970 = :

>>964
フルスタックなFWを使うのをやめれば解決。

971 = :

>>964
そういう話なら、Rails界隈でさんざん議論されてきたことで、例えば
『Rails のモデルはどうあるべきか』
http://tomykaira.hatenablog.com/entry/2013/07/05/231752
とか読む方が、お前の稚拙なコメントよりよっぽど役に立つ。

972 = :

>>967
>>968
Cake の AppModel & Model の内部実装見た事ねーだろ？
あれはモデルじゃなくてDB抽象化クラスだ。
class loaderは命名規約守ってれば何1つ問題無いけど、何が問題になるの？

>>969
何か勘違いしてねーか？
CakeがDBアクセスクラスをModelと命名してしまったせいで、
MVC本来のModelとして俺俺モデル作ってるだけだよ

973 = :

>>964
済みませんがモデルについての是非は別の人とオナシャス
アプリ実装者や各FWがモデルをどう考えてどう設計してるのかには俺も興味あるけど
移植性の話から逸れるしｗ

974 = :

RailsやCakePHPのModelが、MVCにおけるModelとは違うというのは既知の話題。
で、どう実装すべきかというのは>>971にもあるようにさんざん既出。

そういうのはもうどうでもいいので、
>>963
> そもそもの話は>>919
> > フレームワークが消えそうならば、フレームワーク部分を比較的簡単に取り替えられるように
> > 抽象化しておくするべきだ。
に対して意見がないなら、もう黙ってくれる？

976 = :

CakePHPのModelが駄目駄目だと見破った俺すげー自慢

977 = :

>>973
>>974
ああすまん、話逸れてたね。

> そもそもの話は>>919
> > フレームワークが消えそうならば、フレームワーク部分を比較的簡単に取り替えられるように
> > 抽象化しておくするべきだ。

個人的には「無し」だな。
フレームワーク差し替えを考慮するなら、昨今のフルスタックフレームワークを採用するべきでは無い。
アダプタにしろ何にしろ技術的に不可能では無いが、どう考えてもコストもリスクも見合わない。

というか取り替えるシーンが全く思いつかないｗ

978 = :

>>962
> データベースへのアクセス

データベースへのアクセスに使うのはライブラリであって
フレームワークじゃないよ。

979 = :

Railsが馬鹿なんだけど、モデルがActiveRecordを
継承するという設計は間違い。

モデルはActiveRecordを使うが、
モデルはActiveRecordではない。

http://d.hatena.ne.jp/k-sato_at_oiax/20100722/1279803193
> ActiveRecord の後継と目される DataMapper では、継承を使わずに Mix-in を採用していますね。
> 継承を使いすぎたという反省が、Rails 業界にあるんじゃないかと思います。
> 他にも、MongoDB 用の mongoid も Mix-in アプローチを採用しています。

まあだいたい継承し過ぎでやめましょうってなるのは
どのフレームワークでも一緒ｗ

Javaが遠い昔に通りすぎた道。
そしてPOJOにいたる。

未来にはよ来い、PHPフレームワーク使いｗ

981 = :

継承より委託にシフトしてった理由は、単純にテストでの優位性ってのがでかい
継承がダメっていうか、委託するように作っておけば、依存性を注入出来るようにも記述できるから
テスト対象ロジックと対象外ロジックの切り分けがしやすくなる

抽象化ができる部分の継承は悪ではない

馬鹿のいる職場で、データアクセスのライブラリの例外処理の隠蔽や機能制限のためにラッパー噛ませることはあるけど、
フレームワークそのものにラッパーとか何のメリットもないな
再発明とテスト工数の増大を引き起こすデメリットしか見えてこない

982 = :

>>978
そのフレームワークに実装されてるライブラリを使ってたら
いっしょじゃね？

983 = :

委譲を委託と言う奴の言うことなんか聞かないし

984 = :

delegateのことを委託っていう人もいるみたいよ
でもまあ文脈からして委譲の方が正解な気がするけど

985 = :

>>918
このページは「本家」じゃないの？
http://www.curryfw.net/index

最近も更新されてるみたいだが。
2013-09-08　　Curry ver.1.4.10 リリース
2013-08-31　　Curry ver.1.4.9 リリース
2013-06-10　　Curry ver.1.4.8 リリース

986 = :

>985
日本のカレーは本家じゃないでしょ

987 = :

>>978
例え話って話が逸れるから嫌いなんだけどさぁ…
さんま焼き定食に味噌汁がついてくると仮定するでしょ？
別に味噌汁が無くたって成立するけどさぁ
お店がセットで出す限りそれはさんま焼き定食という集合の一部じゃん
さんま焼き定食と言う名の集合に味噌汁を含めるか含めないかなんてお店次第じゃん？
これフレームワークとして置き換えてみたら
ライブラリは味噌汁、コンソールやらツールやらはおしんこって感じにならね？
じゃあさんまは何になるんだろうな

ってずれていくから例え話は嫌なんだよなぁ
でもその主張はおかしいと思うんだよな

988 = :

>>986
Curryの作者って日本人じゃないの？

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / php一覧へ

類似してるかもしれないスレッド

• 【PHP】PHPフレームワーク総合スレ14 (1001) - [97%] - 2010/12/11 10:32
• 【PHP】フレームワークPharonスレ (306) - [75%] - 2022/10/10 20:00
• 【PHP】フレームワークMapleに舌鼓 (470) - [62%] - 2017/12/31 9:31
• 【PHP】フレームワーク Akelos (129) - [59%] - 2019/5/9 7:46
• 2ch有志がPHPフレームワークを作るスレ (81) - [55%] - 2019/5/9 7:46
• 【PHP】Laravel【フレームワーク】 Part.11 (870) - [53%] - 2022/8/28 15:45
• 【PHP】Laravel【フレームワーク】 Part.12 (314) - [53%] - 2023/1/30 18:45
• 【PHP】Laravel【フレームワーク】 Part.10 (446) - [53%] - 2022/6/6 19:30