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

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

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

    551 :

    で、肝心のフレームワークなんだけど
    結局今熱いのってなんなの?

    いっぱいありすぎていまいちこれっていう特徴あるやつ
    ないんだよな~

    最近ちょっとさわってみようかな~って思ってるのあるんだけど
    誰かいじったことある人いたら所感教えて~

    PAJAJ
    http://pajaj.sourceforge.net/

    xFrameworkPX
    http://px.xframework.net/

    552 = :

    PRADOみたいなイベントドリブンなのはどうなんだ

    553 = :

    ちいたんでいい

    554 = :

    やっぱり落ち担当w

    555 = :

    もうちょっとふくらませてからw

    556 = :

    いやらしい

    557 = :

    大規模向けのFWはどれ?

    558 = :

    ちいたん

    559 = :

    出ると思ったw

    560 = :

    ちいたん以外で

    562 = :

    あれ?遅いとか叩いてなかったっけか?
    なぜ大規模向けと?

    563 = :

    軽量なフレームワーク≒自由度が高い≒多人数開発では混乱を招きやすい
    (重量級フレームワーク=動作が遅い)≒自由度が低い=開発のルール化度が高い≒多人数でも均一なコードレベルを保ちやすい

    とはいえ、フレームワークが案件に合う合わないもあるので、
    どのフレームワークを使っても、大規模開発ならプロジェクトのルールが必要だと思われ。
    逆を言えば、ルールさえ作れば軽量なフレームワークでもいいと思う。
    重量級フレームワークが用意してくれる機能を、自分達で実装しないとならないけどね。

    あと、大規模=多人数と勝手に解釈したけど。

    564 = :

    数年がかりの本当に大規模なものなら
    逆に自由度が高いフレームワークを使って自分たちで実装したいって需要もかなりある

    565 = :

    >>564
    開発期間が数年?PHPでそんな案件はほとんど無いけど。

    あと、それを適当にやると、どんどん「フレームワーク」自体に修正が入ってしまって、地層のように
    古いコーディングとより新しいコーディングがどんどん積み重なって手に終えなくなる。
    やるなら、全くいじらないか、最初にきちんと徹底的にいじって固めてしまうのがいいのかな?

    566 = :

    1年未満じゃ大規模とは言えないし

    567 = :

    webアプリで開発に何年もかかってちゃビジネスになんね。

    568 = :

    PHPはインタフェース部分を担当するに過ぎないから
    プロジェクト全体で数年っていうのはあるよ
    複数サイトを作るような事業でも共通フレームワークを作成することはあるし

    569 = :

    単純にスピードを比較したものがよく出るけど、あまり意味無いよな。
    しかも素の状態に近いベンチとか。

    もちろん非常にシンプルに作りたいときにFWの軽さは重要かもしれないけど。
    色々な機能を実装するなら、結局ある程度の重さにはなるだろうし。
    だったら多少重いといわれる高機能FWを使用したほうが開発効率は良いと思う。

    単純なスピード比較がよく話題が出るから、疑問に感じていた。

    570 = :

    何が言いたいのかさっぱりだ
    帰れ

    571 = :

    必要な機能に一番近いものを使えばいいねん
    多すぎず少なすぎず

    572 = :

    それがベストだけどちょうどいいFWってそうはない気も。
    まぁ、一番近いものを選べばいいが

    573 = :

    フレームワークなんて多機能な奴はほとんど一緒だけどね
    パフォーマンスくらいしか差が無い気が

    574 = :

    大規模の意味は100万ユーザ以上が使うというアクセス数の意味で
    開発の工数ではなかったけどためになった

    アクセス数という意味では軽量かどうかが非常に重要と思われ
    サーバの台数などのメンテナンス代が高くつくから

    とはいえ重量級のものを使ってあとからプロファイリングして
    リファクタリングなりすればいいような気もしてきた

    575 = :

    必要な機能なら実装しなきゃならないんだから
    効率的な実装になってるならいいんだけどね
    cakeは実装が酷いよ

    576 = :

    cakeはインターフェイスが全てだからじゃん
    その辺までRailsを踏襲していると言えばそうかも

    577 = :

    ウェブアプリで、大規模って言うと、アクセス数が多いって意味で使われることが多いんじゃないかな。
    でも、それってフレームワークはあんまり関係ないよな。ハードウェアスペックとか、もっと低いレイヤーの問題であって。
    PHPに限らずウェブサイトの開発で数年かけるなんて、まず有り得ないと思う。官公庁のサイトで、手続きが面倒とかでない限り。
    GmailとかGoogle Mapsでもそこまで行かないでしょう。まして、よくあるショッピングサイトやSNSみたいなのに1年も時間使ってたらアフォだよ。

    578 = :

    アクセス数の多さはフレームワークのスレで大規模にあたらないだろ
    1ページだけのHTMLを出力するサイトでも大量アクセスがあれば大規模なのか?
    俺は普通コード量とか機能数だと思うけど

    579 = :

    Googleは独自のフレームワーク作ってそうだけどね
    てか絶対作ってる
    他にも大企業は手の込んだ事やってそうだけどなあ

    580 = :

    ウェブアプリで機能の数って言っても、単に画面を増やしていくだけだからなあ。
    mixiとかamazonとか、確かに画面数は多いけど、結局のところ、掲示板作るのと変わりはない。
    ユーザからの入力を受け取って、何枚かのテーブルを更新して、テーブルをSELECTしなおして、文字列を加工してHTMLに埋め込むって言う。
    これをひたすら繰り返して巨大化するだけ。

    581 = :

    機能によっては違うこともあるんじゃないか。
    ユーザからのデータを何かしら加工するとか、
    なにか特別なアルゴリズムでデータを収集して、
    それを提供するとか。

    582 = :

    WEBAPIの提供に際する共通機能とか
    自動的にDBを保守してくれたりHDD壊れたらバックアップの方へ自動的に繋いで新たなバックアップ先を作るとか
    (PHPコード内の接続先DBサーバIPが動的に変わるって事ね)

    思いつきで書いた

    583 = :

    ウェブアプリで大規模とそれ以外の境目はウェブアプリ側がスケーラビリティを気にする必要があるかどうかだと思う。

    584 = :

    >>580
    > ウェブアプリで機能の数って言っても、単に画面を増やしていくだけだからなあ。
    > mixiとかamazonとか、確かに画面数は多いけど、結局のところ、掲示板作るのと変わりはない。
    > ユーザからの入力を受け取って、何枚かのテーブルを更新して、テーブルをSELECTしなおして、文字列を加工してHTMLに埋め込むって言う。
    > これをひたすら繰り返して巨大化するだけ。

    それはウェブアプリだからではなく、SNSやオンラインショップという
    システムが、そうなっているってだけだろ。

    たとえば、YouTubeのようなウェブアプリではエンコード技術が使われる。


    585 = :

    それにウェブじゃないシステムが何をしているかというと、
    結局、ファイルにデータ読み書きして、画面に点を表示しているだけともいえる。

    586 = :

    大したことやってないのにフレームワークは重いから使わない(キリッ
    なんて言っちゃってる企業とか腐るほどあるからなぁ

    587 = :

    >>585
    インプット・アウトプットの対象の幅広さは、ウェブアプリなんかとは比べものにならんように思う。
    ウェブアプリの場合は、一部APIサービス的なものを除けば、ほぼ「画面」相手でいいわけだが。

    >>586
    その理由でテンプレートエンジンを使いたがらない人も未だに多いがな。同じじゃね?

    588 = :

    フレームワークに比べて、テンプレエンジンは開発効率大してよくならないからな。
    つーかFWに組み込まれてるし

    589 = :

    何かをしない理由にパフォーマンスを上げている場合、大概ちゃんと調べるのとか新しい
    やり方を検討するのが面倒くさいことだけの事が多いと思う。

    論理削除ってあるじゃん。レコードに削除フラグを立ててデータは残すって言う。
    あのフラグのチェックををいちいち手で (del_flag IS NULL OR del_flag = 0) とか書いている
    会社があった。
    なぜ NOT NULL制約を付けないのかと聞いたら、「重くなる」って答えが返ってきた。
    全力でこけた。いろいろ間違ってる。

    590 = :

    12のphp最適化テクニックとか、一時期ブログに出回ったけど、
    そのテクニックが使われるタイミングを考えると、誤差でしかないとか、
    よくあったよね。
    むしろコードが読みにくくなったり、書きにくくなったりと、
    その時間のほうがもったいないとか。

    592 = :

    論理削除自体間抜け

    593 = :

    論理削除自体が間抜け?
    方法がフラグってとこが間抜けってなら少しはわかる気もするが。

    594 = :

    論理削除は必要だろ。

    595 = :

    スレチだけど論理削除ってどういう指定にすればやりやすいですかね。
    active enum('Y','N')か、status = 0 なら削除とか?

    596 = :

    >>593
    わかんね。
    フラグじゃなくてカウンタにするってこと?

    597 = :

    大規模向けではなく一番スケールアウトしやすいFWは?

    598 = :

    スケールアウト考えたらモデルは自分で書かないときつくね?

    599 = :

    ちry

    600 = :

    >>595
    deleted(datetime)がnullかどうか


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

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


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