PHPで大規模なwebappを構築するときにフレームワークを回避することは理にかなっていますか？

ここ数年、PHP Webアプリケーション開発者として、MVCとフレームワークを共有しています。最初はスライスしたパン以来の最高のものだと思いました。すべてが非常に簡単に実装できるように見えました。

しかし今は、アプリケーションが複雑になるほど、フレームワークが導入する手間が増えるようです。そのため、これらを克服するための回避策を開発する必要があります。フレームワークのコアコードを詳しく調べ、変更を加えて思い通りの動作をさせる必要があるため、通常、このような回避策はかなり困難で複雑です。

たとえば、Slim（C）+ Idiorm（M）+ Twig（V）を使用する私のプロジェクトの1つ（これは非常に柔軟だと思います）では、親テンプレートに動的データを表示するだけのカスタム関数を作成する必要があります。フレームワークがなければ、インクルードされたファイルでmysql_query（）を実行するだけで済みました。

わかりました。単純な企業プロファイルWebサイトを作成しているのであれば、フレームワークはすばらしいです。私は一晩でいくつかのコードをホイップすることができ、それらは通常朝までに準備ができており、それらから学んだ優れたコーディング実践とデザインパターンの量は非常に貴重です。

しかし実際には、オールインワンのWebベースの学校管理システムのような複雑なWebアプリケーションの場合、フレームワークは通常、上記の例のように私のビジネスプロセスの邪魔になります。

ですから私の質問は、基本に戻り、標準のPHPコードとライブラリを使用して、膨大なフレームワークとライブラリが存在する可能性がある次のプロジェクトを行うことです。 MVCのような？私の開発チームはかなり小さく、プログラマー2人とデザイナー1人だけです。他のプログラマーは上記の私の考えに同意します。

私の経験はあなたの経験とは正反対です。小さくて迅速なことを行う場合、コードを特定の方法でレイアウトし、先に進む前に注意深く考える必要があるため、フレームワークは少し「邪魔になる」ことがあります。直接ジャンプするだけでmysql_query、プロトタイプをより速く実行できます。

ただし、大規模で複雑なサイトの場合、コードを慎重にレイアウトし、コードの記述方法を実際に考えることは、今後も保守可能なサイトが必要な場合に非常に重要です。

特に、mysql_queryページサイクルのランダムな部分への呼び出しを追加することは、一般的に非常に悪い考えです。ここに1つずつあるかもしれませんが、大した問題ではありませんが、まもなく何十もの場所に散らばり、ページをレンダリングするだけで3秒かかるのではないかと不思議に思っています。または、スキーマを変更し、サイトの関連性がないように見えるセクションが、不明な理由で壊れています。

私の意見では、フレームワークは、開発プロセスが簡単になり、面倒ではない場合にのみ使用する必要があります。特に小規模なプロジェクトの場合、フレームワークを使用しないことや独自のフレームワークを作成することには何の問題もありません。

もちろん、構造とセキュリティの側面に注意を払う必要がありますが、長年フレームワークを使用していることを考えると、おそらくそれらの側面はすでに完全にわかっています。

大規模なプロジェクトの場合、私は他のプロジェクトに同意します。つまり、長期的には、フレームワークを使用することがおそらく最良の選択肢になるでしょう。

サーバーサイドの「フレームワーク」での私の経験は、たとえば次のようにかなり不快です。

A）Jarファイルの地獄（フレームワークが相互に競合している、または相互に互換性のないバージョンのコンテンツについて競合していて、何も知らない、またはデプロイするのを妨げるのでとにかく指示する立場にない）複数のサーバー。

B）何千もの不要なSQL実行への最も単純なオブジェクト作成の破滅的な爆発。

C）2行のJavaをコーディングするよりも、100行のXMLをコーディングする方が簡単または信頼できるという奇妙な概念。

D）完全に不要なサーバー側POJOSを数百行記述して、別のクライアント側オブジェクトにマッピングしたり、場合によっては他の複数の言語（C＃JSなど）にマッピングしたりする必要がある

E）フレームワークの呼び出しに使用したコード行さえ含まれていない30レベルの深いスタックトレースを取得したときに実際に何が起こったかの手掛かりがありません。

反逆者になって、独自のフレームワークを書いてください...最初に他の人があなたが必要だと思ってだましている不要なものをすべて排除することを計画している限り、あなたはそれを後悔しません。そうすれば、すべてを理解でき、MbではなくKbで出荷され、おそらく「どこでも実行」されます。これは、Javaの設立原則の1つでしたね。

「なぜこれが必要なのか...フレームワークを幸せに保つためだけなのか？」と考えてみてください。..それが必要ない場合は、他に何が必要ですか？

Django開発者によるプレゼンテーション方法がありましたが、今は見つけることができませんが、フレームワークによって生産性が向上する「効率の谷」について話しています。

プロジェクトを開始するときにフレームワークの知識がないとすると、最初は生産性が非常に低くなります。つまり、言語の慣用句ではなく、フレームワークの慣習を学習します（うまくいけば、すでに知っています）。

しばらくすると、慣習に取り掛かることになります。これがフレームワークの真の輝きです。突然、生産性は屋根を通り抜け、開発は進歩し、驚くべきスピードで進んでいます。

しかし、最終的には、プロジェクトはフレームワークが恩恵よりも制約となるようなサイズになり、いくつかの機能を試して実装するためにフレームワークに対して手すりを付けていることがわかります。

プレゼンテーションでは、フレームワークの規則についてすでに知識がある場合はもちろん、小規模なプロジェクトでは効率に対する最初の障害はないと述べています。

したがって、小規模なプロジェクト（私の経験では、約500時間未満）の場合、フレームワークを使用した場合の効率は、使用しない場合の効率よりも高くなる可能性があります。特定のしきい値（500〜800時間、IME）に到達すると、フレームワークが提供できるものに制限があることに気付き始めます。

そうは言っても、フレームワークは効率よりもはるかに大きな利点を提供します-SymfonyやDjangoのようなフレームワーク、または（私は想定しています）Railsは、チームが動的に柔軟に対応できるようにし、クライアントまたは製品の所有者がスタッフを変更せずにスタッフを変更できるようにします。新しいシステムを完全に再学習するための新しいリソース-彼らがフレームワークの慣習に精通しており、その慣習が守られている場合、他の場合よりもはるかに生産性が高くなります。

適切に設計されたフレームワークは、プログラマーの助けであり、障害ではありません。使用しているフレームワークが邪魔になりすぎている場合は、別のフレームワークを検討することをお勧めします。それぞれに独自のコーディングスタイルと、独自の長所と短所があります。

そうは言っても、Zendフレームワークは最近非常に人気があり、正直なところですか？時々その理由を理解するのに苦労します。私は過去にそれを使用しなければならなかった、そして私はそのアーキテクチャが少し好きではなかった。Zend_Formクラスは途方もなく過剰に設計されており、そのデコレータシステムはまったく使用されていないため、デコレータはフォームをビューに結び付け、オブジェクトを疎結合にする必要があるというOOPの根本的な概念を打ち破っています。また、多くのコードがシングルトーンとして実装されており（十分に文書化されているので、繰り返しにならないため、これは良くありません）、Registryオブジェクトは、ずさんなコーディングスタイルを助長する原因にもなります。

Zend Framework 2（現在はベータ版）の方がはるかに優れた製品であると聞きましたが、Zend 1の味が悪いので、すぐに試してみることができます。

それでも、現時点では私はただ怒っています。:)フレームワークはたくさんあり、それぞれに長所と短所があります。それらのいくつかを評価することをお勧めします。

あなたが説明することは、過去に「抽象化によって引き起こされた複雑さ」と呼ばれてきました。それを管理することに関する唯一の論文は、David KeppelによるAbstracting-Induced Complexityの管理です。ケッペルは、フレームワークが抽象化によって引き起こされる複雑さを引き起こす設計を持っていることを示唆するでしょう。

フレームワークで作業することは、ホイールを再発明しないことで開発をスピードアップするのに役立ちます。Frameworkは、アプリケーションを適切に設計するのに役立つツールも提供します（ただし、ビューから直接データベースにアクセスするなど、設計上の不適切な決定を防ぐことはできません）。

場合によっては、カスタム機能が必要なときに、適切に書き込むのに時間がかかることがあります。しかし、常にハッキングして回避策を見つけている場合は、フレームワークに取り組んでいるか、フレームワークがニーズに適合していません。

結論はこれです。単純なプロジェクトに大きなフレームワークを使用する（たとえば、データベースからいくつかのフィールドを表示する）と、やり過ぎになる場合があります。大規模または複雑なプロジェクトの場合は、フレームワークを使用します。

独自のコードを作成することと、フレームワークを使用することには、いくつかの側面があります。

作業しているチームの規模、基本的な知識、経験：フレームワークを使用したことがない場合、またはアプリケーションを構築する方法についてアイデアがあり、多くの例を備えた十分に文書化されたフレームワークを使用して、速度を上げることがわかった場合アップ。

アプリケーションのサイズ：どのように使用されるかは事前にわかりません。ですから、成長と変化に備えておくべきです。あなたが一晩でコーディングしたいあなたのフレームワークは、経営者のニーズとともに成長することができますか？DBのフィールドタイプを変更すると、実装に1分または1日かかります。それがここでのポイントです。

準備：フレームワークを使用する場合は、アプリケーションのコアをコーディングする代わりに、アプリケーションの設計を開始できます。セキュリティとデプロイメントが重要な部分であるフレームワークを使用してください。これには時間がかかります。毎回。

Symfony2はウェブ開発のフレームワークであるため、私は常に「管理」について議論します。経営陣はそれが大きすぎると考えており、学習曲線が急であるため、費用がかかり、プログラマーを遠ざけるでしょう。

フレームワークは、現代のあらゆる言語、特に大規模なプロジェクトで引き続き使用されます。プロジェクトが大きくなるほど、フレームワークの重要性が増します。そのため、すべてのロジックがどこにあるのかがわかり、すべての機能のレイアウトが似ています。これにより、すべてのデータアクセスまたはすべてのプレゼンテーションを探す場所、またはビジネスルールが管理される場所がわかっている場合に、プロジェクトの変更と学習が容易になります。

ただし、プロジェクトに適合するフレームワークを選択する必要があります。エンタープライズソリューションには、エンタープライズ対応のフレームワークが必要です。これは、PHPを使用するときに遭遇する問題です。多くの（ほとんどの）フレームワークは、大規模での使用を意図したものではありませんが、小規模な個人サイトでは問題なく機能します。あなたが言及する学校の管理システムのようなものについては、より堅牢なフレームワークが必要になるでしょう、そしてPHPで適切なフレームワークを見つけるのにしばらく時間がかかるかもしれません。