元スレ【PHP】PHPフレームワーク総合スレ15
php覧 / PC版 / みんなの評価 : △
前へ
901 = :
iphone用の画面に特化したのがほしい
903 = :
もぅCakeはいいだろ・・・
904 = :
Cakeがいやならパンを食べればいいじゃない
905 = :
いいねえ今度のFWの名前が決まったな
906 = :
マリーアントワネットフレームワークか。
907 = :
マリー・アントワネット・ジョゼファ・ジャンヌ・ド・ロレーヌ・ドートリシュ フレームワーク
910 = :
パンが無ければクッキーを焼けばいいじゃない
秒間4億枚くらい
911 = :
BbaPHP です
913 = :
cookieとか ややこしいだろ
915 = :
おれおれCookieClickerが簡単につくれるそうでいいね
916 = :
つくれるそうって誰からの伝聞だ
917 = :
クーキーはbbaがつえーからなぁ
918 = :
最近 Curry というフレームワークの存在を知って、
気に入って使い始め、ある程度作りこんだ矢先に本家ウェブサイトが消えてしまった。
作者様の身に何があったのかは分からないけど、マイナーなフレームワークは
こういうことになると、情報の参照先が完全になくなるから困っちゃうな。
作者様、これ見てたらどうか復活してください。
919 = :
>>918
それはフレームワークに使われてる
段階だからだめなんだよ。お前の技術不足。
まずフレームワークはどれも対して変わらない。
ステートフルなフレームワークみたいに発想そのものが違うものはあるが
同じ発想で作られているものは基本的に同じ。
機能が実装されてるかまだ実装されてないかの違いだけ。
だから長く使われそうなフレームワークを選ぶべき。
もちろん、いろんな事情でマイナーなフレームワークを使うことが
ダメとは言わないが、その場合はフレームワークに依存しないように作るべき。
つまり、今回、お前がやらなければならなかったこと。それが出来ないのはお前の技術不足。
フレームワークが消えそうならば、フレームワーク部分を比較的簡単に取り替えられるように
抽象化しておくするべきだ。そしてコアの部分はフレームワークに依存させないように開発する。
それが出来るように、技術を磨けよ。
920 = :
>>919
しかと受け止めました。
親切にありがとうございます。感謝です。
921 = :
>>919
> フレームワークが消えそうならば、フレームワーク部分を比較的簡単に取り替えられるように
> 抽象化しておくするべきだ。
ムリムリ
922 = :
それ以前にフレームワークを更に抽象化させようとする意図が掴めない
実際にZend Framework/Symfony/CakePHP/FuelPHPに対する具体的なコードを見せてもらいたいな
923 = :
フレームワークを抽象化するフレームワークですね解ります
924 = :
>>921
お前には無理なの？
そうか、そうなんだね。
925 = :
>>922
フレームワークを抽象化させてどうするのさｗ
誰もフレームワークを抽象化するなんて言ってないし。
ヒント、デザインパターンより
・Adapter パターン
互換性のないインタフェースを持つクラス同士の接続を可能にします。
926 = :
はずれのFWを選んだってだけのことだろう
927 = :
>>925
フレームワークが用意した仕組みを無視して
自作のラッパークラスを使えって事？
アホくさい
928 = :
>>927
だからお前は馬鹿なんだ。
Adapterって言ってるだろ、
フレームワークが用意した仕組みを使うからこそ
Adapterなんだってわからんのか？
930 = :
まぁ言葉遊びとかどうでもいいから具体的なコードを見せてくれ
自分が知ってるフレームワーク間だけのでいい
こっちはあんたの理想とやらをどう具体化してるのか知りたいんだからさ
931 = :
>>920
だからさAdapterを使う＝フレームワークが用意したAPIも使う
という意味であるということを、理解できてないのはなんで？
あんたは話をする最低レベルにすら到達してないんだけど？
932 = :
>>930
Adapterパターンって言ってるだろ。
それでわからんのか？
933 = :
つーかさ、ユニットテストどうやってるのさ？
お前の作ったアプリは、当然ブラウザなしでも
メインの処理行えるよな？
（ユニットテストでは通常ブラウザは使わない）
あとは、そのメインの処理をフレームワークと
つなげるAdapter作るだけじゃん
最低限度の基礎知識さえ知ってれば、わかることだよ？
934 = :
>>932
悪いがエスパーじゃないんでね
Adapterで何と何を繋げるんですかね
コード出してくんなきゃ話が進まないんだけど
935 = :
> メインの処理をフレームワークと
> つなげるAdapter作るだけじゃん
読めないの？ｗ
936 = :
>>935
> コード出してくんなきゃ話が進まないんだけど
読めないの？
937 = :
>>936
出すつもりはないよ。
だから、最初っからヒントって書いただろｗ
自分で考えろって意味さ。
938 = :
>>937
コードはもういいけどよ
言葉遊びは止めろつってんだろ馬鹿野郎
Adapterは実装手段であって目的じゃねぇんだよ馬鹿
APIの差異を吸収するレイヤーを作れとなんで一言で表せねぇんだよ
アプリケーションへのHTTP Requestを表すオブジェクトに対するAPIを例にしたらこうだろ？
+----------------------------------------------
| アプリケーション
+-----------------------------------------------
| オレオレRequest API
+---------------------+---------------------+--
| Symfony 2#Request API | CakePHP#Request API | ..
+-------------------------------------------+----
このオレオレAPIを挟むのがアホくさいってんだよ
ボトムアップで機能を殺していくアホの設計
知識の共有化をスポイルするアホの所業
939 = :
> Adapterは実装手段であって目的じゃねぇんだよ馬鹿
いつAdapter が目的だといった？
お前本当に馬鹿じゃないのか？
> このオレオレAPIを挟むのがアホくさいってんだよ
その図を考えたのは誰だ？
おまえだよな。
その図は間違いだ。
つまり、お前は間違いを書いたんだ。
アホ？ アホはお前だろう？
940 = :
> APIの差異を吸収するレイヤーを作れとなんで一言で表せねぇんだよ
「APIの差異を吸収するレイヤーを作れ」と言うわけがないだろ。
そんなもん作らないんだから。
本当にアホだなぁｗ
941 = :
>>939-940
じゃAdapterをどこで何に使おうと思ったのかな？
あ、コードを出す気はないし答えも言わないんだったな
もう1人で後出しジャンケンやっててくれや
942 = :
>>941
もう触るな。Adapterの意味すらわかってないよきっと
943 = :
>>938
普通にフレームワーク使ってても、拡張すると俺俺層が出来てくるだろ？
MVCガッチリかみ合ったフルスタックFWを、他のFWに置き換えるのは相当しんどいけど、
一部機能を載せ替えるのは案外楽だよ。
アダプタでもいいし、プラグインでも拡張でも、何でも･･････
ただ意味があるのかどうかは知らん。
944 = :
>>943
> 普通にフレームワーク使ってても、拡張すると俺俺層が出来てくるだろ？
何のフレームワークを使ってて、どの部分にどんな俺俺層ができるの？
945 = :
>>943
俺俺層自体を否定してませんよ
拡張のために自分も普通に作りますからね
でも「FWの移植に備えるため」には用意しません
アダプターを介して使えと言われた側はそれで済むから別にいいです
で、移植する先のアダプターを用意する人は誰なんですか、結局自分でしょ？
そのアダプターは移植する前の機能を備えていないといけない、移植先でも動くようにしなければいけない
移植する未知のFWがどんな設計なのかも分からないのにできるんです？
モデル/ビュー/コントローラー/データベースへのインターフェイス/マイグレーション/コードジェネレーター/etc...
出来たとしてもキリがないですよ
そしてFWに変更があれば「自分のアダプターも更新しないといけない」、やる気になれないでしょ…
銀の銃弾みたいに抽象化だのアダプターだの言ってるから
どう対応するのか、どう設計するのかを知りたかったんですけどね
口先だけの人みたいだからがっかりですわ
946 = :
未来永劫、一人で開発してメンテナンスもするということが確実なら、趣味で膨大な俺俺層を作ってもかまわないけど。
947 = :
新しい言語を覚える必要の無いフレームワーク ってある？
948 = :
>>945
えとさ、お前の書いたアプリのメインロジックって
なんかのフレームワークに依存しちゃってるの？
普通POPO（Plain Old PHP Object）で作るよね？
もしメインのロジックまでフレームワークに依存していたら
やばい。フレームワークを乗り換えることもできないし
フレームワークが死んだら大変なことになるよ。
949 = :
素人がFWを使うより、玄人が作った俺俺コードの方が遙かに保守性が高いし、
長期運用考えるならFWのメンテナンスより、DB設計や機能単位の切り分け設計の方が遙かに大事だ
950 = :
> 素人がFWを使うより、玄人が作った俺俺コードの方が遙かに保守性が高いし、
不要な単語が多いので重要な点だけ抜き取りますね。
> 素人より、玄人の方が遙かに保守性が高いし、
当たり前じゃね？
みんなの評価 : △
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
トップメニューへ / →のくす牧場書庫について