のくす牧場
コンテンツ
牧場内検索
カウンタ
総計:127,647,340人
昨日:no data人
今日:
最近の注目
人気の最安値情報

元スレ【PHP】フレームワークについて語るスレ13【総合】

php覧 / PC版 /
スレッド評価: スレッド評価について
みんなの評価 :
タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。
←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitter
551 = :

DIでいいじゃん

552 = :

>>549

>>522
> > 後からスケールアウトしやすく設計されているフレームワーク

> 実際、無いよなあw

お前はFWを使いこなせてないだけ。

553 = :

>>552
はいはい僕ちゃんは使いこなせてて凄いでしゅねー

554 = :

おまいら仕事しろよ

555 = :

>>549>>522が言ってる「スケールアウト」を勘違いしてそう

556 = :

>>549
レスありがとう
自分自身の感覚になってしまうけど、
CakeにしろSymfonyにしろ(この2つしか例に出せないゴメン)、
十分にスケールアウトを考慮した設計になってると思うよ。
でも逆に言えば、サーバ一台で完結させるような場合には、どうしてもオーバーヘッドが出て来るよね

むしろ本当に書き捨てでいいアプリならば、これらを使わずに
「俺俺」や「素のPHP」でもいいと思う。というかむしろそうする。

557 = :

>>555
ん?
俺は>>522読んで、(アクセス規模に対する)スケールアウトという言葉の用例が、
DBレプリケーションやmemcacheにかかってるんだと思ってた。

>>556
アクセス規模が増えてDBレプリケーションやmemcacheを使いたくなった時に、
Cakeやsymfonyだと簡単に移行できるかどうかって話だよね?

>>511と同じく、個人的にはそうは思えなかったけど、改めて調べてみると、
CakeではDBレプリケーション対応は簡単みたいだね。Propel13はダメだ(反論求む)
それに後付けのmemcache対応はどっちでも難しい。(反論求む)
sfSuperCacheも後付けで使うには設計を直す必要があるし(反論求む)
URIの変更もsfRouteやroutesだけの設定じゃ厳しい(ずれてる?)

559 = :

>>557

ZendFWを勉強してみたら良い。君の言う問題は全て解決する。

560 = :

ZFは他のFWに比べると書くコード量が一回り増えるけどなw

561 = :

>>560
そこがFWとして魅力を感じないよね・・
CakePHPのライブラリとして使うと結構その辺を補えるという話を聞くけど

562 = :

memcacheなんてもともとシンプルなんだから自分でクラス書けばすぐじゃん
dbの分散化対応は面倒くさいけど

563 = :

memcacheってほんの数行のサンプルコードしかみてないんだけど
たんに良くあるキャッシュコードでファイルに保存する代わりに
メモリに保存してるだけだろ?

564 = :

PHPってやっぱりドイツの普及率が一番低いのかな?
ドイツ発のフレームワークってないし

565 = :

イギリス発とかフランス発とかのフレームワークなんてあるのかい?

566 = :

フレームワークは全部韓国発ですよ?

567 = :

symfonyはフランス発だよ

568 = :

ドイツ発PHPフレームワーク誕生!その名もadolf

569 = :

>>559
kwsk

>>562
DBレプリケーションも、それ前提で自作すりゃ簡単だろうさ。
memcacheもそうで、key-value型のホルダを先に作っておけば移行は容易。

でもmemcacheでやりたい事がテーブルやクエリ結果のキャッシュだったら、
それはフレームワーク備え付けのDBアクセス手段じゃ実現困難だよねって話。

571 = :

>>569

>でもmemcacheでやりたい事がテーブルやクエリ結果のキャッシュだったら、
>それはフレームワーク備え付けのDBアクセス手段じゃ実現困難だよねって話。

>>562は、この点↑を含めて、既存のDBアクセス周りをラップする
クラスを作ればいいんじゃね?って言ってるんだと思うぞ

それに何でもかんでもmemcache頼みってのもどうかと思うぞ
DB周りのメモリチューニングとか、あるいはオンメモリDBを使うとか
その辺は検討したのか?

572 = :

>>571

> それに何でもかんでもmemcache頼みってのもどうかと思うぞ

ごめん、memcacheの話は自分が最初に振っちゃったので、
>>549 (>>569)関係ない。
自分は>>549 (>>557) 読んで、まあ確かに、config書き換えですぐに対応出来る訳ではないよなーと
思った。

573 = :

もうそろそろkey-value方式の
フレームワークが出ても良いと思うんだ。

574 = :

>>573
普通にCakePHPは対応してるでしょ

575 = :

違うか普通にキャッシュとして対応してるのか

576 = :

>>575
そういうこと。

キャッシュではなくモデルがkey-valueを基礎としているフレームワーク

O/Rつかってリレーショナルなデータをオブジェクトに変換するより
楽じゃないかと思うけどな。

ストレージとして、barkleyDBのようなkey-valueなデータベースだけじゃなく
ファイルやRDBにも格納できる設計で。

577 = :

>>571
> 既存のDBアクセス周りをラップするクラスを作ればいいんじゃね?

DBの結果セットをmemcachedに移行するというアプローチは、
自分でやった時はうまくいかなかったなあ。
結局、ご指摘の通りにオンメモリにして逃げちゃった。

なので、簡単に後付けで移行出来る方法があるなら良いなぁと思ったし、
無いんでないかなーと>>549で言っちゃった。

>>573-576
東京なんちゃら対応のなんちゃらモジュールがCakePHPで動くらしいね。
Cakeはよくよく調べてみるとみんなで結構何とかしちゃってる感がある。

578 :

チャットプログラム作ってって言われた。相手はシロートさん&レンタルサーバってコトで、PerlかPHPの二択にほぼ決定。
Perlは正直「使える」程度なんでPHPにしようと思うんだが、Pearを使わないでファイルコピーで設置完了することが可能なFWってあるかな?
一応SymfonyはSandbox使えば可能なのは知ってるが、流石に少々重たいかと思ってね。

・・・ま、「チャットごとき素のPHPで書けよ」ってのは御説ごもっともなんだがw、
どうもバリデータやHTML/SQLサニタイズを手で書くのは億劫になってね。
FWに慣れすぎたかもw

579 = :

FWに慣れすぎた人の質問とは思えないw

580 = :

もしかしてPEARしか触ったことないんじゃ?

581 = :

>>578
いまどき PEAR 使う FW はない
簡単なプログラムなら CodeIgniter でいいんじゃない?

583 = :

ちいたんで萌え萌えチャットを(ry

584 = :

>>578
ぜったい釣りだろ、お前w

587 = :

どうせ個人的に使うチャットだろうし
全部1クラスにまとめたようなレトロな作りにしても十分じゃね
FTPでアップロードして権限振ったらすぐ使えます、のほうがいいような相手なんでしょ

大体バリデーションつっても、入力文字の<>&あたり置換すりゃ早々問題なんて起きんだろうし
ログだってファイルにはいていいんじゃね、小一時間もありゃ書けるでしょ

つか、578の場合レンタルでも探したほうがいいんじゃねw
そっちのほうが間違いなく多機能で安全で優れてるとおもうぞ

588 = :

>578
fitzgerald。本体が269行しかない。
http://www.moongift.jp/2009/06/fitzgerald/
バリデータは存在しないので自分で書かんといけないが。
一番面倒な、入力を一括してフィルタリングする機構はあるのでさほどの手間はない。

あと、エスケープ/サニタイズが面倒なのはお前が阿呆なだけ。
面倒ならエスケープしてからビューに渡す関数とか作れよ。

589 = :

関数を作るのもめんどくせえー

590 = :

まともなプログラマなら、小規模用の俺俺ライブラリくらい持ってるだろw
FWに慣れたっつーより、FWが無ければ何も出来ないの間違いじゃね?

正規表現とかもかけないんじゃね?w

591 = :

「相手はシロートさん」にワロタ
おめーも大差ないですよっと

592 = :

PHP使いにまともなプログラマっているの?

593 = :

いるわけねーだろ

594 = :

まともという言葉がどこをさすのかによるだろうな

595 = :

何度目だよ

596 = :

Regexクラスとかできちゃいそうだよね

597 = :

まともなプログラマは言語に依存せず、要件に見合ったコードを書く
PHPかどうかは関係無いし、PHPにも職人クラスのPGはいる。


ただ勘違いした「シロートさん」比率が、他の言語より圧倒的に多いww

598 = :

Pealのにわかプログラマに比べればまだマシだけどな

599 = :

PHPはどうしても冗長だからな。

600 = :

PHPは取っつきやすいからな。
で、上達するに連れ、言語仕様に不満が出てくる。
そして、他の言語へ移る。

Web用言語の登竜門みたいなもんだから、仕方ないべ。
今更Perlから入る人も少ないでしょうし。

グローバル関数をクラスライブラリ化して、型宣言もアリにして、
OO言語に生まれかわらんかな。

既存のグローバル関数で発生したエラーを例外処理化したライブラリはないかな?


←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / php一覧へ
スレッド評価: スレッド評価について
みんなの評価 :
タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。

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


トップメニューへ / →のくす牧場書庫について