この質問は、Cake PHP、Zend、jQuery、ASP.NETなどのWebベースのフレームワークを使用する利点と欠点を抽出することに焦点を当てています。この質問は完全に言語に依存しません。「巨人の肩に立つ」という概念から始めましょう。

利点：

• 開発者を支援 -以前は数百行のコードを使用していた機能を1つの単純な関数呼び出しに圧縮することにより、開発者はより複雑な機能をWebサイトに統合できます。
• 許可迅速化開発アプリケーションの-これは必要性のウェブサイトは非常に小さなウィンドウで作成した人のために非常に関連している（誰これのいずれかの例を持っています？）
• 低コスト -プログラマーはコスト削減を顧客に回すことができます。これは、まったく新しい顧客がウェブサイトを望んでいましたが、以前は高い開発コストを払うことができませんでした。

短所：

• 理解の喪失 -開発者は、フレームワークの機能に依存するため、物事がどのように機能するか（フードの下）の理解を失う危険にさらされています。
• 構成の限界-フレームワークの構成よりも先に進むと、生産性がすぐに低下するため、フレームワーク構成の外部で機能を実装することは困難です。
• 開発者のトラムライン -あなた（開発者）は、開発者があなたにしたいやり方で物事をしなければなりません。

人々は私の主張をどう評価しているのか、そして誰かがそれらに同意していないのだろうか？また、人々が追加のポイントを持っている場合、私は感謝するでしょう。

要点は次のとおりです。フレームワーク構成外で機能を実装するのは難しい場合があります。

この仮定を仮定ごとに見ていきましょう。

理解の喪失-開発者は、フレームワークの機能に依存するため、物事がどのように機能するか（フードの下）の理解を失う危険にさらされています。

偽。あなたは物事がどのように機能するかの理解を失うことは決してありません。フレームワークは魔法ではありません。これらは、自分で書く必要のない便利なコードです。

信じられないかもしれませんが、フレームワークを使用すると間違いを犯します。何が間違っていたかを理解するには、HTTPの最低レベルまでデバッグする必要があります。

ボンネットの下で何が起こっているかを見失うことはありません。もちろん、フレームワークが非常に壮大で完璧で、問題が発生しない限りは別です。

構成の限界-フレームワークの構成よりも先に進むと、生産性がすぐに低下するため、フレームワーク構成の外部で機能を実装することは困難です。

これはほとんど意味がありません。

最初。フレームワークなしで構築することで、単体テスト、デバッグ、診断、構成制御、およびフレームワーク内にあるものを再発明する他のすべての価値のない作業を含む大規模なプログラミングタスクを簡単な作業にすることができます。その「生産性」はどうですか？

第二に。フレームワークの外部に物事を実装することは常に多くの作業です。フレームワークの学習と構成に費やした時間とは関係ありません。フレームワークの外部で何かを実装することは本質的に困難です。

開発者のトラムライン-あなた（開発者）は、[フレームワーク]開発者があなたにしたいことをしなければなりません。

正しい。そして、これはしばしば良いことです。一貫した方法で物事を行うことは、自分の好みの方法で行うことよりも価値があります。「学習」と「理解」が必要かもしれませんが、これらには価値があります。

セキュリティの問題-プロフェッショナルなWebサイトを迅速に開発するためのこれらのツールを人々に提供することは潜在的なリスクです。

何？これはフレームワークとは関係ありません。詐欺は、使用されているツールに関係なく詐欺です。

短所：サポートの最終的な低下/人気の喪失

• 基本的に同じことを行う2つのWebフレームワークがあり、あなたのフレームワークが勝てない場合、プロジェクトが死ぬ可能性があります。この状況では、フレームワークを自分で管理する（オープンソース）か、アプリケーションを書き直すか、更新なしで続行するか（クローズドソース）が残っています。
• フレームワークによっては、フレームワークのリリーススケジュールに合わせてアプリケーションをアップグレードしなければならない場合があります。遅れすぎると、サポートを受ける資格がなくなる可能性があります。フレームワークなしで、あなたはあなたのスケジュールで働くことができます。（これは、サポートが必要かどうかによって異なります）。

プロ：ビジネス向けのコード

• フレームワークを使用すると、面倒な作業を心配せずに、ビジネスに直接価値をもたらすコードに集中できます。
• フレームワークをアップグレードして（機能するだけで）ユーザーに新しい機能を実質的に「無料」で提供できる場合があります。特に、カスタムコントロールを備えたフレームワーク（新しいバージョンが何らかの検索/フィルターを提供する可能性のあるグリッドなど）。

長所

• 開発時間の短縮
• 少ないバグ
• より迅速な共有開発
• 図書館サポート
• 簡単なDBインタラクション

欠点

• フレームワークへの「ボックス化」
• 多くの場合、コアの動作を拡張または変更する場合に柔軟性がありません
• 「運命のエラー」–コアまたは基礎となるアーキテクチャーから発生したエラーで、それらが発生した場所への適切なトレースバックはありません。完璧な例は、Grailsを使用しているときのSpringエラーです。

私は、最も単純なプロジェクト以外のすべてにフレームワークを使用することを推奨しています。お問い合わせフォームを既存のHTMLサイトに追加する必要がある場合は、フレームワークに移動する代わりに1つのPHPファイルを使用できます。

頭に浮かぶいくつかのことは...

長所

• コードの再利用-フレームワークを使用することで、テスト済みの真のコードを再利用できます。
• 迅速な開発/プロトタイピング。
• （多くの場合）安全であると推定される統合入力検証（開発者がそれを正しく使用している場合）

欠点

• サポートの喪失。ここで思い浮かぶのはSymfony 1.4です。Symfonyはしばらく1.4をサポートすると思いますが、2.0には後方互換性がないことを知っているので、1.4は今後数年で行き止まりになりそうです。
• オーバーヘッド; フレームワークを使用すると、特定のアプリケーションには適用されないが、他のアプリケーションには適用される可能性がある数千の行を実行しています。これを合理的なトレードオフとみなす人もいれば、パフォーマンスのためにゼロからコードを書くことを選択する人もいます。
• 特定のニーズに合った間違ったフレームワークを使用する。すべてのフレームワークが均等に作成されるわけではありません。

それはすべて、使用するフレームワークに依存します。

ASP.NETを使用している場合、あなたは不利な立場にあります：それはせいぜい漏れやすい抽象化であり、最悪の場合、あなたがいるという事実を隠さない他のフレームワークでは些細なことをするのは苦痛になりますウェブでの作業。

ASP.NET MVCはその問題を解決しようとしていますが、それはうまくいきます。

フレームワークが存在するため、作業を完了するためにより多くの時間を費やすことができ、足場を構築する時間を短縮できます。その点で、足場の構築に本当に時間を費やしたいのでなければ、デメリットはありません。

私はいくつかのポイントを追加したいと思います。

• 私が見つけたフレームワークの最大の問題の1つは、人々が考えることをやめることです。フレームワークを使用したいのは、それがクールだから、または常にフレームワークを使用しているからです。彼らは、使用が正当化されるかどうか考えることをやめないでください。
• ライセンスは、人々が実際にライセンスを見なくてもフレームワークを使用しているように見えます。これは、彼らがオフに気づいていないという意味を持ちます。または、ライセンスが変更されたときにどうなるかを考えてください。
• 同じ種類のフレームワークの多くに使用します。時には、実際にはほとんど同じことを行う多くのフレームワークになることがあります。会社として、あなたは教育された選択を行い、プロジェクトごとに異なるフレームワークを持っているわけではありません。
• 新しいバージョンについていくのは難しいかもしれません

それでも、フレームワークの評価、ライセンスの評価、使用ごとのフレームワークのクリーンなリストを保持し、スマートなバージョン管理戦略を立てるためにもう少し努力することは、利点を検討するときに価値があると思います。

利点：

• フレームワークを一貫して使用すると、プロジェクトの学習時間は、既にプロジェクトに取り組んでいる人にとっては減少します。
• 独自の迅速な開発
• あなた自身の開発者に力を与える

私は過去13年間の個人的な経験から話しています。私の会社では、ストラットを使用しましたが、短い曲線の後、それは素晴らしかったです。私の次の段階では、ほとんど不透明で成長したアーキテクチャを使用しましたが、拡張できましたが、コアコードはjarのみでした。等々。過去3年間に小さな会社（devの数は30未満）で働いていましたが、それはすべて私たち自身のjsp、サーブレット、ejbsでした。複数のクライアントとjspの繰り返しを見ると、2012年には20％のstruts2を模倣するj2eeフィルターを作成することになりました。なぜstuts 2を使用しないのですか？私たちが持っていたらいいのにと思います。十分な経験や時間がない。

そのため、ミニフレームワークが使用する一般的なjspをインターセプターに入れました。今、私はStruts 2の本を読む時間がありましたが、私たちはとても逃したことがわかります！

私たちはいくつかの素晴らしいアルゴリズムとキャッシュとUIを使用していますが、多くの時間を失い、3年間の廃止を計画している多くのコードを抱えています。