私は最近、友人に Catalyst (Perl) を学び始めていると話しました。彼は、Catalyst には非常に多くの依存関係があるため、代わりに Rails のようなものを使用する必要があることをかなり強く強調しました。
依存関係が多いのは良いことではないでしょうか。これは、多くのコードが再利用されていることを示していませんか? フレームワークのインストールに手間がかかることは承知していますが、他にデメリットはありますか?
有益な回答が得られるまで、 Catalyst チュートリアルを再開します。:-)
これには特に問題はありません。Catalystの利点は、Catalystのすべてを使用していない人でもその部分を使用できることです。これは、重要な部分を見てバグを修正する目が増えることを意味します。
私が聞いた最大の不満は、Catalystのインストール中にCPANシェルでこれらすべてのメッセージが通過するのを見るのが面倒だということです。解決策は、開始時にOSのパッケージマネージャーを利用することです。Debianでは、apt-get install libcatalyst-perl他のPerlモジュールがインストールされていないマシンにインストールするのに15秒かかります。15秒。（単純なCPANのインストールも難しくありませんが、標準のCPANシェルは多くのばかげた質問をするので、初心者を先延ばしにしていると思います。）
依存関係について心配する必要はありません。依存関係を管理するための優れたツールがあり、フレームワークをより強力で柔軟にします。
これは私が以前に投稿を見た主題です。私はそれについての記事を書くつもりでした、そしてついにそうしました。
ここにあります：独立の嘘
ぜひお読みください。ただし、要点は単純です。質問は間違っています。「依存関係の多いアプリケーションやフレームワークを使用していますか、それとも依存関係のないアプリケーションやフレームワークを使用していますか？」
それは次のとおりです。「外部依存関係がたくさんあるアプリケーションまたはフレームワークを使用しますか、それともすべてを内部で実行しようとしますか？」
そして、次の質問は、「このフレームワークを作成している人は、Webリクエストを処理するために実行する必要のあるすべてのタスクの細部の微妙な違いをすべて理解していると本当に信じていますか？」
コンポーネント間にバージョンの依存関係がある場合、互換性のあるバージョンの依存コンポーネントが利用可能になる前に (セキュリティ上の理由などで) 1 つのコンポーネントをアップグレードせざるを得ない場合、動作しない状況に陥ることがあります。
これは、そもそも作業状態に入ることができることを前提としています。すべての依存関係の現在のバージョンを使用しようとすると、うまくいかないことに気付くかもしれません。
依存関係の数が多いほど、リスクは大きくなります。
Rails にもこの問題がないわけではありません。新しい Ruby がリリースされるたびに、たとえばデータベース ドライバーをビルドする方法などの手順を更新するために、慌ただしい作業が行われます。
公平を期すために、この問題は時間の経過とともに「改善」される傾向にありましたが、途中で問題が発生しました。
私の個人的な経験では、依存関係が多いほど、追跡する必要のあるバージョン管理が多くなり、悪夢のような状況につながる可能性があります。特に、1つの依存関係を更新すると（たとえば、修正したいバグが原因で）、他の依存関係との互換性の問題が発生する可能性があります。例として、私は個人的に、gcc 4.0.3がfooで動作するが、barでは動作しない（fooの依存関係）、gcc 4.0.5はbarで動作するが、fooでは動作しないという状況がありました。幸い、4.0.2は機能しました。
また、「フランケンシュタインの怪物」製品は、一緒にプレイするように事前に設計されていないパーツで構成されているため、依存関係が増える傾向があります。十分に統合されたフレームワークは、優れた一貫性のある再生を実現するように設計されています。もちろん、これは違いを適切にラップすることで修正できます。