トップページ⇒php
989コメント277KB

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

レス数が950を超えています。1000を超えると書き込みができなくなります。
0001nobodyさん2010/12/12(日) 10:47:08ID:???
PHPのフレームワークに関する話題用のスレッド

●国外産●
symfony
　ttp://www.symfony-project.com/
code igniter
　ttp://codeigniter.com/
Zend Framework
　ttp://framework.zend.com/manual/ja/index.html
CakePHP
　ttp://www.cakephp.org/
Yii Framework
　ttp://www.yiiframework.com/

●国産
ちいたん
　ttp://php.cheetan.net/
Ethna
　ttp://ethna.jp/
guesswork
　ttp://classic.guesswork.jp/
maple
　ttp://kunit.jp/maple/

●前スレ
【PHP】PHPフレームワーク総合スレ14
http://hibari.2ch.net/test/read.cgi/php/1253912143/
0921nobodyさん2013/09/24(火) 17:43:04.97ID:???
>>919
> フレームワークが消えそうならば、フレームワーク部分を比較的簡単に取り替えられるように
> 抽象化しておくするべきだ。

ムリムリ
0922nobodyさん2013/09/24(火) 19:08:13.80ID:???
それ以前にフレームワークを更に抽象化させようとする意図が掴めない
実際にZend Framework/Symfony/CakePHP/FuelPHPに対する具体的なコードを見せてもらいたいな
0923nobodyさん2013/09/24(火) 21:08:01.67ID:???
フレームワークを抽象化するフレームワークですね解ります
0924nobodyさん2013/09/24(火) 21:47:36.34ID:???
>>921
お前には無理なの？
そうか、そうなんだね。
0925nobodyさん2013/09/24(火) 21:49:35.35ID:???
>>922
フレームワークを抽象化させてどうするのさｗ
誰もフレームワークを抽象化するなんて言ってないし。


ヒント、デザインパターンより

・Adapter パターン
互換性のないインタフェースを持つクラス同士の接続を可能にします。
0926nobodyさん2013/09/24(火) 22:03:44.04ID:???
はずれのFWを選んだってだけのことだろう
09279222013/09/24(火) 22:36:34.00ID:???
>>925
フレームワークが用意した仕組みを無視して
自作のラッパークラスを使えって事？
アホくさい
0928nobodyさん2013/09/24(火) 23:04:33.77ID:???
>>927
だからお前は馬鹿なんだ。

Adapterって言ってるだろ、
フレームワークが用意した仕組みを使うからこそ
Adapterなんだってわからんのか？
09299222013/09/24(火) 23:10:53.37ID:???
>>928
s/仕組み/API/
これでいいか？

フレームワークが用意したAPIを無視して
自作のラッパークラスを使えって事？
アホくさい
09309222013/09/24(火) 23:15:26.20ID:???
まぁ言葉遊びとかどうでもいいから具体的なコードを見せてくれ
自分が知ってるフレームワーク間だけのでいい
こっちはあんたの理想とやらをどう具体化してるのか知りたいんだからさ
0931nobodyさん2013/09/24(火) 23:16:10.92ID:???
>>920
だからさAdapterを使う＝フレームワークが用意したAPIも使う
という意味であるということを、理解できてないのはなんで？

あんたは話をする最低レベルにすら到達してないんだけど？
0932nobodyさん2013/09/24(火) 23:17:10.95ID:???
>>930
Adapterパターンって言ってるだろ。
それでわからんのか？
0933nobodyさん2013/09/24(火) 23:19:54.02ID:???
つーかさ、ユニットテストどうやってるのさ？
お前の作ったアプリは、当然ブラウザなしでも
メインの処理行えるよな？
（ユニットテストでは通常ブラウザは使わない）

あとは、そのメインの処理をフレームワークと
つなげるAdapter作るだけじゃん
最低限度の基礎知識さえ知ってれば、わかることだよ？
09349222013/09/24(火) 23:22:06.99ID:???
>>932
悪いがエスパーじゃないんでね
Adapterで何と何を繋げるんですかね
コード出してくんなきゃ話が進まないんだけど
0935nobodyさん2013/09/24(火) 23:22:41.55ID:???
> メインの処理をフレームワークと
> つなげるAdapter作るだけじゃん

読めないの？ｗ
09369222013/09/24(火) 23:26:29.62ID:???
>>935
> コード出してくんなきゃ話が進まないんだけど
読めないの？
0937nobodyさん2013/09/24(火) 23:30:21.71ID:???
>>936
出すつもりはないよ。

だから、最初っからヒントって書いただろｗ
自分で考えろって意味さ。
09389222013/09/24(火) 23:54:23.97ID:???
>>937
コードはもういいけどよ
言葉遊びは止めろつってんだろ馬鹿野郎
Adapterは実装手段であって目的じゃねぇんだよ馬鹿
APIの差異を吸収するレイヤーを作れとなんで一言で表せねぇんだよ
アプリケーションへのHTTP Requestを表すオブジェクトに対するAPIを例にしたらこうだろ？

+----------------------------------------------
|　　　　　　　　　　　アプリケーション
+-----------------------------------------------
|　　　　　　　　　　 オレオレRequest API 　　　　　　　　　　　
+---------------------+---------------------+--
| Symfony 2#Request API | CakePHP#Request API | ..
+-------------------------------------------+----

このオレオレAPIを挟むのがアホくさいってんだよ
ボトムアップで機能を殺していくアホの設計
知識の共有化をスポイルするアホの所業
0939nobodyさん2013/09/24(火) 23:59:20.52ID:???
> Adapterは実装手段であって目的じゃねぇんだよ馬鹿

いつAdapter が目的だといった？
お前本当に馬鹿じゃないのか？

> このオレオレAPIを挟むのがアホくさいってんだよ
その図を考えたのは誰だ？
おまえだよな。

その図は間違いだ。
つまり、お前は間違いを書いたんだ。

アホ？ アホはお前だろう？
0940nobodyさん2013/09/25(水) 00:00:47.86ID:???
> APIの差異を吸収するレイヤーを作れとなんで一言で表せねぇんだよ

「APIの差異を吸収するレイヤーを作れ」と言うわけがないだろ。
そんなもん作らないんだから。

本当にアホだなぁｗ
09419222013/09/25(水) 00:09:46.28ID:???
>>939-940
じゃAdapterをどこで何に使おうと思ったのかな？
あ、コードを出す気はないし答えも言わないんだったな
もう1人で後出しジャンケンやっててくれや
0942nobodyさん2013/09/25(水) 00:17:11.53ID:???
>>941
もう触るな。Adapterの意味すらわかってないよきっと
0943nobodyさん2013/09/25(水) 02:07:57.17ID:???
>>938
普通にフレームワーク使ってても、拡張すると俺俺層が出来てくるだろ？

MVCガッチリかみ合ったフルスタックFWを、他のFWに置き換えるのは相当しんどいけど、
一部機能を載せ替えるのは案外楽だよ。

アダプタでもいいし、プラグインでも拡張でも、何でも･･････
ただ意味があるのかどうかは知らん。
0944nobodyさん2013/09/25(水) 11:03:10.72ID:???
>>943
> 普通にフレームワーク使ってても、拡張すると俺俺層が出来てくるだろ？

何のフレームワークを使ってて、どの部分にどんな俺俺層ができるの？
09459222013/09/25(水) 12:15:05.05ID:???
>>943
俺俺層自体を否定してませんよ
拡張のために自分も普通に作りますからね
でも「FWの移植に備えるため」には用意しません

アダプターを介して使えと言われた側はそれで済むから別にいいです
で、移植する先のアダプターを用意する人は誰なんですか、結局自分でしょ？
そのアダプターは移植する前の機能を備えていないといけない、移植先でも動くようにしなければいけない
移植する未知のFWがどんな設計なのかも分からないのにできるんです？
モデル/ビュー/コントローラー/データベースへのインターフェイス/マイグレーション/コードジェネレーター/etc...
出来たとしてもキリがないですよ
そしてFWに変更があれば「自分のアダプターも更新しないといけない」、やる気になれないでしょ…

銀の銃弾みたいに抽象化だのアダプターだの言ってるから
どう対応するのか、どう設計するのかを知りたかったんですけどね
口先だけの人みたいだからがっかりですわ
0946nobodyさん2013/09/25(水) 13:04:36.04ID:???
未来永劫、一人で開発してメンテナンスもするということが確実なら、趣味で膨大な俺俺層を作ってもかまわないけど。
0947nobodyさん2013/09/25(水) 13:42:24.47ID:???
新しい言語を覚える必要の無いフレームワーク ってある？
0948nobodyさん2013/09/26(木) 00:22:22.68ID:???
>>945
えとさ、お前の書いたアプリのメインロジックって
なんかのフレームワークに依存しちゃってるの？

普通POPO（Plain Old PHP Object）で作るよね？


もしメインのロジックまでフレームワークに依存していたら
やばい。フレームワークを乗り換えることもできないし
フレームワークが死んだら大変なことになるよ。
0949nobodyさん2013/09/26(木) 00:26:33.55ID:???
素人がFWを使うより、玄人が作った俺俺コードの方が遙かに保守性が高いし、
長期運用考えるならFWのメンテナンスより、DB設計や機能単位の切り分け設計の方が遙かに大事だ
0950nobodyさん2013/09/26(木) 00:27:57.62ID:???
> 素人がFWを使うより、玄人が作った俺俺コードの方が遙かに保守性が高いし、

不要な単語が多いので重要な点だけ抜き取りますね。


> 素人より、玄人の方が遙かに保守性が高いし、

当たり前じゃね？
0951nobodyさん2013/09/26(木) 00:29:13.95ID:???
玄人＋FW　　＞　　玄人＋俺俺 　　＞＞＞＞＞＞　　素人＋FW≒素人＋俺俺

まあ当たり前の話だよ。
0952nobodyさん2013/09/26(木) 00:51:35.13ID:???
当たり前だよな

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

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

traitsとか使い始めたら世界は崩壊する
0953nobodyさん2013/09/26(木) 00:59:00.10ID:???
訂正

×でも、PHPのFW使いの大半は
○>>952とその仲間たちはプログラマとして素人だ。
0954nobodyさん2013/09/26(木) 01:30:14.76ID:???
誰かと思えばBootstrapスレで暴れてたキチガイじゃねぇか
0955nobodyさん2013/09/26(木) 01:45:57.23ID:???
>>954
つまりあなたは両方のスレで暴れているということですね？
0956nobodyさん2013/09/26(木) 01:53:27.43ID:???
今度はフレームワークをセマンティックしに来たか
0957nobodyさん2013/09/26(木) 01:54:49.62ID:???
なんか他のスレで暴れていた奴が
こっちに逃げてきてるな。

こっち来んな。はげ
09589222013/09/26(木) 03:24:14.21ID:???
>>948
俺はフレームワークに躊躇なく依存するよ
普通と言うなら基本的にフレームワークが用意しているベースモデルを継承して
そこにビジネスロジックを書くのが普通なんだけど
RailsでもDjangoでもフルスタックのものは大抵そのスタイルだしね

POJOを持ち出すからそれについても突っ込むけど
Java界隈じゃ継承の代わりにアノテーション使ってるだけでやってる事は変わんないぜ？
結局はそれを解釈するフレームワークに依存してるんだしな
0959nobodyさん2013/09/26(木) 03:45:35.60ID:???
継承はベースクラスがないと
クラス単体で使えない。

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

この点でぜんぜん違うわけだが？
0960nobodyさん2013/09/26(木) 03:47:49.12ID:???
> 俺はフレームワークに躊躇なく依存するよ
具体的に、どのフレームワークの
どのクラスに依存するのか書いてみ。

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

お前のモデルはなんのクラスを継承するのだ？
0961nobodyさん2013/09/26(木) 05:12:20.88ID:???
>>958
>>960
ビジネスロジックがFW依存するのは、FWと共に命運を共にするなら有りじゃね？

そもそもベースモデルが存在するFWって何よ？
大抵はモデルという名のORM実装じゃねぇ
09629222013/09/26(木) 10:52:21.81ID:???
>>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でもなんでもいいよ
ビジネスロジックがどうのとかモデルはこうあるべきなんて焦点にしてないから
俺の主張はフレームワークが決めた方法に従え、
移植のために小細工なんてせずに使えって事だ
0963nobodyさん2013/09/26(木) 10:54:01.11ID:???
>>960
> 念の為に言っておくが、ロジック、
> つまりモデルの話だぞ。
なんでここまで後退してるんだ？

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

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

「フレームワーク部分を比較的簡単に取り替えられるように」するためには、Modelのみならず、
当然Controller/View部分も対応しておく必要がある。
09649612013/09/26(木) 13:05:02.91ID:???
>>962
＞俺の主張はフレームワークが決めた方法に従え、
＞移植のために小細工なんてせずに使えって事だ
そこは同意する。

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

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

これは、DB操作クラスを内包する本来の意味でのモデルを作るのが正解だと思う。
俺はCakeを使う場合 CakeMdodel(DB) ⇔ 俺俺モデル ⇔ CakeController という方法で実装している
0965nobodyさん2013/09/26(木) 13:31:41.16ID:???
>>964
> 俺はCakeを使う場合 CakeMdodel(DB) ⇔ 俺俺モデル ⇔ CakeController という方法で実装している

糞実装の見本
0966nobodyさん2013/09/26(木) 13:37:24.22ID:???
>>965
お前がモデルを理解していない事だけはわかった
黙ってBakeしてろ
0967nobodyさん2013/09/26(木) 13:44:01.17ID:???
>>964
それ、俺俺モデルの内容をCakeModelで実装すればいいだけじゃないの？
分離するとclass loaderとか面倒なことになりそうな気がするが、それを上回るメリットは？
0968nobodyさん2013/09/26(木) 13:49:37.71ID:???
俺俺モデルというか、AppModelを継承して、Cakeの枠組み内で実装すればいいんじゃ？
0969nobodyさん2013/09/26(木) 13:51:24.17ID:???
つか、CakePHPのModelのありようが気にくわないならCakePHP使うなって話だな
0970nobodyさん2013/09/26(木) 13:57:12.12ID:???
>>964
フルスタックなFWを使うのをやめれば解決。
0971nobodyさん2013/09/26(木) NY:AN:NY.ANID:???
>>964
そういう話なら、Rails界隈でさんざん議論されてきたことで、例えば
『Rails のモデルはどうあるべきか』
http://tomykaira.hatenablog.com/entry/2013/07/05/231752
とか読む方が、お前の稚拙なコメントよりよっぽど役に立つ。
0972nobodyさん2013/09/26(木) 14:06:08.18ID:???
>>967
>>968
Cake の AppModel & Model の内部実装見た事ねーだろ？
あれはモデルじゃなくてDB抽象化クラスだ。
class loaderは命名規約守ってれば何1つ問題無いけど、何が問題になるの？

>>969
何か勘違いしてねーか？
CakeがDBアクセスクラスをModelと命名してしまったせいで、
MVC本来のModelとして俺俺モデル作ってるだけだよ
09739222013/09/26(木) 14:06:19.56ID:???
>>964
済みませんがモデルについての是非は別の人とオナシャス
アプリ実装者や各FWがモデルをどう考えてどう設計してるのかには俺も興味あるけど
移植性の話から逸れるしｗ
0974nobodyさん2013/09/26(木) 14:18:12.43ID:???
RailsやCakePHPのModelが、MVCにおけるModelとは違うというのは既知の話題。
で、どう実装すべきかというのは>>971にもあるようにさんざん既出。

そういうのはもうどうでもいいので、
>>963
> そもそもの話は>>919
> > フレームワークが消えそうならば、フレームワーク部分を比較的簡単に取り替えられるように
> > 抽象化しておくするべきだ。
に対して意見がないなら、もう黙ってくれる？
0975nobodyさん2013/09/26(木) 14:21:09.47ID:???
そもそもCakePHPがDBアクセスクラスをModelと命名したんじゃなくて、RoRをまねしたから似たような役割になっただけ
0976nobodyさん2013/09/26(木) 14:27:17.56ID:???
CakePHPのModelが駄目駄目だと見破った俺すげー自慢
0977nobodyさん2013/09/26(木) 14:29:46.82ID:???
>>973
>>974
ああすまん、話逸れてたね。

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

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

というか取り替えるシーンが全く思いつかないｗ
0978nobodyさん2013/09/26(木) 21:55:37.62ID:???
>>962
> データベースへのアクセス

データベースへのアクセスに使うのはライブラリであって
フレームワークじゃないよ。
0979nobodyさん2013/09/26(木) 21:59:41.06ID:???
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フレームワーク使いｗ
0980nobodyさん2013/09/26(木) 22:17:57.79ID:???
>>979
素人がtraitを覚える
↓
フレームワークの使い方がよくわからない＞＜
↓
traitで拡張しよっと（＾ｐ＾)俺スーパープログラマだ
↓
カオス
0981nobodyさん2013/09/27(金) 09:15:53.75ID:???
継承より委託にシフトしてった理由は、単純にテストでの優位性ってのがでかい
継承がダメっていうか、委託するように作っておけば、依存性を注入出来るようにも記述できるから
テスト対象ロジックと対象外ロジックの切り分けがしやすくなる

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

馬鹿のいる職場で、データアクセスのライブラリの例外処理の隠蔽や機能制限のためにラッパー噛ませることはあるけど、
フレームワークそのものにラッパーとか何のメリットもないな
再発明とテスト工数の増大を引き起こすデメリットしか見えてこない
0982nobodyさん2013/09/27(金) 10:41:57.45ID:???
>>978
そのフレームワークに実装されてるライブラリを使ってたら
いっしょじゃね？
0983nobodyさん2013/09/27(金) 10:43:12.19ID:???
委譲を委託と言う奴の言うことなんか聞かないし
0984nobodyさん2013/09/27(金) 10:46:04.84ID:???
delegateのことを委託っていう人もいるみたいよ
でもまあ文脈からして委譲の方が正解な気がするけど
0985nobodyさん2013/09/27(金) 10:53:54.89ID:???
>>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 リリース
0986nobodyさん2013/09/27(金) 14:06:46.92ID:???
>985
日本のカレーは本家じゃないでしょ
0987nobodyさん2013/09/27(金) 14:45:36.09ID:???
>>978
例え話って話が逸れるから嫌いなんだけどさぁ…
さんま焼き定食に味噌汁がついてくると仮定するでしょ？
別に味噌汁が無くたって成立するけどさぁ
お店がセットで出す限りそれはさんま焼き定食という集合の一部じゃん
さんま焼き定食と言う名の集合に味噌汁を含めるか含めないかなんてお店次第じゃん？
これフレームワークとして置き換えてみたら
ライブラリは味噌汁、コンソールやらツールやらはおしんこって感じにならね？
じゃあさんまは何になるんだろうな

ってずれていくから例え話は嫌なんだよなぁ
でもその主張はおかしいと思うんだよな
0988nobodyさん2013/09/27(金) 14:51:14.47ID:???
>>986
Curryの作者って日本人じゃないの？
0989nobodyさん2013/09/27(金) 14:59:08.31ID:???
Curryを作ったのが誰かわからないが、
・http://www.objective-php.net/ の記述
・Curry本体のファイルのCopyrightが"www.curryfw.net" になっている
ということから、http://www.curryfw.netは本家で、作者は日本人だと思う。
レス数が950を超えています。1000を超えると書き込みができなくなります。