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

**nobodyさん** · 2010/12/12(日) 10:47:08

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/

**nobodyさん** · 2013/09/26(木) 13:57:12.12

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

**nobodyさん** · 2013/09/26(木) NY:AN:NY.AN

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

**nobodyさん** · 2013/09/26(木) 14:06:08.18

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

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

**922** · 2013/09/26(木) 14:06:19.56

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

**nobodyさん** · 2013/09/26(木) 14:18:12.43

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

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

**nobodyさん** · 2013/09/26(木) 14:21:09.47

そもそもCakePHPがDBアクセスクラスをModelと命名したんじゃなくて、RoRをまねしたから似たような役割になっただけ

**nobodyさん** · 2013/09/26(木) 14:27:17.56

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

**nobodyさん** · 2013/09/26(木) 14:29:46.82

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

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

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

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

**nobodyさん** · 2013/09/26(木) 21:55:37.62

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

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

**nobodyさん** · 2013/09/26(木) 21:59:41.06

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フレームワーク使いｗ

**nobodyさん** · 2013/09/26(木) 22:17:57.79

>>979
素人がtraitを覚える
↓
フレームワークの使い方がよくわからない＞＜
↓
traitで拡張しよっと（＾ｐ＾)俺スーパープログラマだ
↓
カオス

**nobodyさん** · 2013/09/27(金) 09:15:53.75

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

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

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

**nobodyさん** · 2013/09/27(金) 10:41:57.45

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

**nobodyさん** · 2013/09/27(金) 10:43:12.19

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

**nobodyさん** · 2013/09/27(金) 10:46:04.84

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

**nobodyさん** · 2013/09/27(金) 10:53:54.89

>>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 リリース

**nobodyさん** · 2013/09/27(金) 14:06:46.92

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

**nobodyさん** · 2013/09/27(金) 14:45:36.09

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

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

**nobodyさん** · 2013/09/27(金) 14:51:14.47

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

**nobodyさん** · 2013/09/27(金) 14:59:08.31

Curryを作ったのが誰かわからないが、
・http://www.objective-php.net/ の記述
・Curry本体のファイルのCopyrightが"www.curryfw.net" になっている
ということから、http://www.curryfw.netは本家で、作者は日本人だと思う。