トップページ⇒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/
0876nobodyさん2013/08/21(水) NY:AN:NY.ANID:???
エディタとしても便利だけど、負の遺産コードを読むツールとして便利だよ＞最近のIDE
HTMLやSQLやJSが混在していても、それぞれの定義元に飛べたりするし。

>>870
Sublimetext は文脈を解析しての補完はしてくれなくね？

$hoge = new Hoge();
$unknown = $hoge->getHogeeeee(); .// 戻り値も定義元も不明

の後に

$unknown->

とタイプすると、どこまで補完してくれるんだろ。
0877nobodyさん2013/08/21(水) NY:AN:NY.ANID:???
延々とIDEの話してる奴はスレタイ読めないアホなの？
0878nobodyさん2013/08/21(水) NY:AN:NY.ANID:???
IDEも大きな視点で見ればフレームワークの一環だよね
0879nobodyさん2013/08/21(水) NY:AN:NY.ANID:???
>>875
「)」が邪魔になる例としては http://jsdo.it
0880nobodyさん2013/08/21(水) NY:AN:NY.ANID:???
>>876
そんな補完してくれなくていいよ
0881nobodyさん2013/08/21(水) NY:AN:NY.ANID:???
<?php
って打ったら俺の仕事が全部補完されてるIDEを教えてください(*´艸｀*)
0882nobodyさん2013/08/21(水) NY:AN:NY.ANID:???
同僚の井出さんは、すっごい仕事のできる人で、プログラミングのみならず全て補完してくれます。
ただし有料です。
0883nobodyさん2013/08/21(水) NY:AN:NY.ANID:???
オチがわからない・・・解説たのむ。
0884nobodyさん2013/08/21(水) NY:AN:NY.ANID:???
井出 = I DE

だろ？
0885nobodyさん2013/08/22(木) NY:AN:NY.ANID:???
>>880
補完はどうでもいいけど、定義元が解るのは他人の書いたコードを読む時に捗る
0886nobodyさん2013/08/29(木) NY:AN:NY.ANID:???
CodeIgniterはMVC初学者にとっては良い学習用フレームワークである
いまどきのフレームワークはComposerを使った外部ライブラリと依存する方向へシフトしてきている
それに加えて、開発元はCodeIgniterを手放そうとしている
CodeIgniterに未来は描けなくなった
もはやCodeIgniterを選択するべきではない

では、何を選択するのがよいか？
中規模 CakePHP|Laravel|FuelPHPのいずれか
大規模 Symfony
0887nobodyさん2013/08/29(木) NY:AN:NY.ANID:???
長いものにまかれるためにSymfony2使ってる。
国内だと1.xがまだ現役ぽいけど
0888nobodyさん2013/08/29(木) NY:AN:NY.ANID:???
Symfony2 どうよ？
個人的にCLIツール群はいらんのだけど、ビジネスロジック部実装するにあたって便利だなぁって思う機能ある？
0889nobodyさん2013/08/29(木) NY:AN:NY.ANID:???
仕事でやるならCLIになれとかないと
0890nobodyさん2013/08/30(金) NY:AN:NY.ANID:???
CodeIgniterは、開発元とか将来性とか気にするほどのものじゃないだろ
興味があったら使えばいいし、嫌になったらやめればいいし、気軽に使えよ
0891nobodyさん2013/08/30(金) NY:AN:NY.ANID:???
CLIで作業する事はあってもsymfony コマンドとか使いたくねぇなぁ
0892nobodyさん2013/09/01(日) 23:27:46.95ID:???
Rainってどうなの？
http://www.rainframework.com/
テンプレートは使いやすかったけど。
0893nobodyさん2013/09/03(火) 08:47:07.13ID:???
>>892
エラーでまくり
0894nobodyさん2013/09/05(木) 14:06:33.98ID:???
PHP5.5に変えてから、pearライブラリで、
「Fatal error: Call-time pass-by-reference has been removed in 」が
頻出するようになった。修正が面倒くさい。いい方法ない？
0895nobodyさん2013/09/05(木) 15:17:10.75ID:???
PEAR パッケージ のアップデートじゃない？
種類によっては修正パッチみたいなのもあるようだけど
http://pear.php.net/bugs/bug.php?id=19773&;edit=11
0896nobodyさん2013/09/05(木) 22:44:37.69ID:???
>895
なるほど。ありがとうございます。早速アップデートしてみます。
0897nobodyさん2013/09/08(日) 21:29:25.23ID:???
久しぶりに来たら、CakePHPのスレってなくなってる？
0898nobodyさん2013/09/10(火) 11:16:37.81ID:???
composer使っている人いる？
0899nobodyさん2013/09/10(火) 12:05:31.36ID:???
fuelPHP使ってると、コンポーザー使わざるを得ない
0900nobodyさん2013/09/10(火) 23:05:24.16ID:???
fw自体の更新も楽だからcomposer使ってる
0901nobodyさん2013/09/11(水) 13:57:49.61ID:???
iphone用の画面に特化したのがほしい
0902nobodyさん2013/09/11(水) 16:36:08.93ID:???
LichKing使ってる人いる？
0903nobodyさん2013/09/15(日) 01:54:00.91ID:???
もぅCakeはいいだろ・・・
0904nobodyさん2013/09/15(日) 11:33:28.84ID:???
Cakeがいやならパンを食べればいいじゃない
0905nobodyさん2013/09/15(日) 12:42:17.58ID:???
いいねえ今度のFWの名前が決まったな
0906nobodyさん2013/09/15(日) 13:15:59.35ID:???
マリーアントワネットフレームワークか。
0907nobodyさん2013/09/15(日) 13:16:39.28ID:???
マリー・アントワネット・ジョゼファ・ジャンヌ・ド・ロレーヌ・ドートリシュ フレームワーク
0908nobodyさん2013/09/17(火) 22:55:26.99ID:???
PanPHPだな。
0909nobodyさん2013/09/18(水) 19:07:57.77ID:???
BreadPHPだろ、ってツッコミいれたら負けですか？

bakeコマンドはそのまま使えますね
0910nobodyさん2013/09/19(木) 12:29:06.16ID:???
パンが無ければクッキーを焼けばいいじゃない

秒間4億枚くらい
0911nobodyさん2013/09/19(木) 12:29:49.29ID:???
BbaPHP です
0912nobodyさん2013/09/19(木) 21:13:59.55ID:???
CookiePHPとかありそう
0913nobodyさん2013/09/20(金) 01:27:43.21ID:???
cookieとか ややこしいだろ
0914nobodyさん2013/09/20(金) 05:46:01.40ID:???
CookiePHPは紛らわしいからCookieClickerPHPにすれば良いね
0915nobodyさん2013/09/20(金) 11:53:33.64ID:???
おれおれCookieClickerが簡単につくれるそうでいいね
0916nobodyさん2013/09/20(金) 17:57:06.17ID:???
つくれるそうって誰からの伝聞だ
0917nobodyさん2013/09/21(土) 00:06:49.29ID:???
クーキーはbbaがつえーからなぁ
0918nobodyさん2013/09/21(土) 16:00:33.76ID:???
最近 Curry というフレームワークの存在を知って、
気に入って使い始め、ある程度作りこんだ矢先に本家ウェブサイトが消えてしまった。
作者様の身に何があったのかは分からないけど、マイナーなフレームワークは
こういうことになると、情報の参照先が完全になくなるから困っちゃうな。
作者様、これ見てたらどうか復活してください。
0919nobodyさん2013/09/21(土) 20:19:16.11ID:???
>>918
それはフレームワークに使われてる
段階だからだめなんだよ。お前の技術不足。

まずフレームワークはどれも対して変わらない。
ステートフルなフレームワークみたいに発想そのものが違うものはあるが
同じ発想で作られているものは基本的に同じ。
機能が実装されてるかまだ実装されてないかの違いだけ。

だから長く使われそうなフレームワークを選ぶべき。

もちろん、いろんな事情でマイナーなフレームワークを使うことが
ダメとは言わないが、その場合はフレームワークに依存しないように作るべき。
つまり、今回、お前がやらなければならなかったこと。それが出来ないのはお前の技術不足。

フレームワークが消えそうならば、フレームワーク部分を比較的簡単に取り替えられるように
抽象化しておくするべきだ。そしてコアの部分はフレームワークに依存させないように開発する。
それが出来るように、技術を磨けよ。
09209182013/09/21(土) 23:17:38.05ID:???
>>919

しかと受け止めました。
親切にありがとうございます。感謝です。
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をまねしたから似たような役割になっただけ
レス数が950を超えています。1000を超えると書き込みができなくなります。