多くの人がコンテンツ リポジトリを使用していることを考えると、正当な理由があるはずです。コンテンツを保存する必要がある新しい Web アプリケーションを構築しています。誰かがこれを理解するのを手伝ってくれますか?
独自のコード/API を記述して画像やテキスト ページを保存するのではなく、Apache Jackrabbit のようなコンテンツ リポジトリを使用する利点は何ですか? 独自の作成には時間がかかりますが、コンテンツ リポジトリ API などの新しいフレームワークの実装と学習にも時間がかかります。自分で開発する利点は、自分のコードを知っていて、それを強化または修正する必要がある場合にすぐに専門知識を持っていることです。別のフレームワークを使用するには、その弱点を学ぶ必要があり、知っているが知らないコードを変更する方が常に簡単です...つまり、その基礎となるフレームワークコードも自分自身のものも知らない.
おっしゃる通り、使っている人が多いです。理由があるはずです。「みんなが使っているから、私たちもそうすべきだ」としか思えません。少なくともそうではないことを願っています。:)
JCR リポジトリを使用すると、すべてのコンテンツ (構造化されたデータベース タイプのデータから大規模なマルチメディア ファイルまで) を 1 つの場所に 1 つの API で保存できます。これは非常に便利で、コードをよりシンプルにし、ファイルとデータ間のインピーダンスの不一致を回避します。コンテンツベースのシステムに通常あるものです。
JCR は、検索 (フルテキストを含む)、監視 (何かが変更されたときのコールバック)、バージョン管理、複数値を含むデータ型、順序付きノードなど、自分で構築または組み立てる必要のない多くのインフラストラクチャ機能も提供します。 .
恥知らずなプラグインを許可する場合は、 http://java.dzone.com/articles/java-content-repository-bestにある私の「JCR - 両方の長所」の記事で、これについて詳しく説明し、参考文献リストも提供します。 JCR仕様。これにより、全体を読まなくても概要を把握できます。
この記事では例として Apache Sling を使用しています。JCR リポジトリと組み合わせると、コンテンツ ベースのアプリケーションに非常に優れた (IMO ですが、Sling コミッターとして偏見があります ;-) プラットフォームが提供されます。
私の最近のプロジェクトには、マルチレベルのキャッシュメカニズムを備えたカスタムビルドのデータストア（MySQLおよびイメージファイル）と、JCRベースの商用リポジトリの両方の選択肢が含まれています。いくつかの考え：
短期的には、DIYソリューションは複雑さを軽減します。必要なものを構築して学習するだけです。また、少なくとも特定のアプリケーションのニーズに合わせてデータストアを最適化する機会があります。検索の速度はおそらくそれ以上ですが、ストレージのフットプリント、セキュリティ、または信頼性の問題が何よりも重要です。
ただし、長期的には、自社開発のシステムを新しいコンテンツタイプ（ビデオなど）に拡張したり、新しい機能（バージョン管理など）を提供したりするための作業が大幅に増加することを考えています。
また、データストアアプローチの選択と、コンテンツプロバイダーがデータストアへの入力と保守に使用するツールの選択を区別することは困難です。テキストエリアと送信ボタンを備えたHTMLフォーム以上のものを作成者に提供する必要があります。
これは、互換性と互換性という標準化の利点に関連しています。誰もが独自のライブラリと API を作成すると、互換性と互換性がなくなり、コストが高くなります。