ゼロから構築するのではなく、確立されたCMSを選択するのはなぜですか？
今後数週間にわたる私の研究の多くは、さまざまなCMSに関するものです。私はすでにエピサーバーとウンブラコについて簡単に説明しました。これらのシステムを読んでいる間、コンテンツ管理機能を提供することは、これらの（かなり大きな）CMSプラットフォームの多くの詳細と構造を理解することなく達成できると思わざるを得ません。
私は過去に、開発者としての私の役割を編集者の役割とは別に保つ必要があるプロジェクトが与えられました（理にかなっています）。つまり、サイトのデザインと機能を開発することが私の仕事であり、コンテンツを更新するのはクライアントの仕事でした。テキスト入力や画像のアップロードなどを受け入れるページがいくつかあるような「ポータル」を実装することでこれを実現しました（基本的に、彼らが望むコンテンツなら何でも）、この新しいコンテンツをデータベースに記録してから、設計により、コードビハインドはこれをすべてデータベースから関連するコントロール（リピーターなど）に読み込みます。
私にとって、これは私のソリューションで展開するコンテンツをクライアントが管理するのに十分効果的な方法でした。私は間違っていること、そしてCMSはゼロから構築されたものよりも好ましいことを知っていますが、コストの問題以外に、なぜですか？
既存のCMSを使用して、追跡する必要のないユーザーにとっておそらく重要な機能の重みを取り除きます。
EPiServer、Umbraco、Orchardなどにはすべて、バージョン、他のコンテンツによってリンクされているコンテンツ、フォームの作成方法などを追跡するための組み込みオプションがあります。さらに、それらをフックして変更できるイベントがあります。あなたは合うと思います。
通常、何千時間ものトラブルシューティングが既に行われているので、それらを活用してみませんか。特に、無料またはオープンソースバージョンでは、文字通りコストはかかりませんが、APIを習得する時間は、ほぼ保証できますが、その機能を作り直すよりも短い時間です。
それで、それらが提供する機能を再構築する必要がない限り、うまく機能することがすでに知られているものを使用してみませんか？
自分で実装する必要がない既存の機能の簡単なリストを次に示します。
- コンテンツのバージョン管理
- ワークフロー
- ページリンクステータスレポート
- wysiwygエディターのカスタマイズ
- コンテンツモデリング（ページタイプ/ドキュメントタイプ）
- コンテンツ取得API
- 編集者と開発者の両方のためのドキュメント/トレーニング
- オブジェクトキャッシング戦略
- 検索用コンテンツクエリシステム
- コンテンツ階層構造（とにかくコンテンツがツリー形式であるCMS内）
- エディタービュー
- 管理ビュー
- アクセス制御
[〜＃〜] no [〜＃〜]どちらが良いかについての明確な答えがあります。それは、お客様のニーズ、構造、コスト、人的資源、およびその他の要素に依存します。
既製/確立されたCMS
長所
- 時間の節約LOT。何年も前から存在しているCMSの中には、非常に多くの人時間を費やしているものがあります。既製のCMSの機能の10％は必要ないかもしれませんが、それでも時間を節約でき、時間は無料ではありません！
- LOTのお金を節約できます。
- 一般に、[〜＃〜]巨大な[〜＃〜]の機能があり、おそらくニーズに対応します。
短所
- ライセンス。使用する既製のCMSのライセンスに従う必要があります。これは大したことではないかもしれませんが、ライセンスで禁止されているものを変更したい場合や、実稼働環境での使用が禁止されている場合があります。
- 重い。 CMSは、できるだけ多くのオーディエンスに到達するように調整される可能性が高いためです。サーバーに制限があるか、基本的なコンテンツ管理のために過剰なスクリプトをロードしたくない場合があります。
- モジュール形式ではない可能性があります。事前に作成されたCMSを実装し、クライアントがサインオフしてデプロイする準備ができたWebサイトが完成したとします。次に、それをクライアントに向けて撮影すると、「ああ、この機能をCMSに追加したい！」次に、非常に複雑な、またはあまりモジュール化されていないCMSを選択した場合、それらの機能要求の実装に問題があるか、過度に時間がかかる可能性があります。
- バグを継承します。 CMSの既存のすべてのバグを継承します。通常は簡単に更新できるので問題ありませんが、機能を追加するためにその一部を大幅に変更した場合はどうなりますか？
自家製/カスタムCMS
長所
- ニーズに合わせて調整されます。必要なものだけを統合でき、高い移植性を維持できます。
- あなたの言語で書かれています。多分あなたはASP.net MVCウェブサイトを持っていて、そこにあるすべてのCMSはPHPで書かれていますが、MVCとかみそりビューエンジン（idkランダムな例）を使用してC＃で書かれたものが必要です。均一で巨大なPHP/JSなどのないWebページを維持する方がはるかに簡単です。すべてのC＃コードの真ん中にあるCMS。
- Yoursあなた/あなたの会社は100％所有しています。追加のライセンスを購入しなくても、好きなだけ多くのアプリケーションで使用できます。
短所
- 時間がかかるので、高価です。投入された時間、経験などに応じて、CMSの作業に数十日を費やすことができます。
時間があって、既製のシステムがどれも法案に適合しないか、あまりにも複雑である場合、もちろん時間のかかる要素以外に、独自のシステムを構築しない理由はないと思います。
ディスカッションにWebセキュリティを追加することもできます。 CMSを最初から構築する場合、多くの攻撃に対して脆弱になる可能性があります（例 https://www.owasp.org/index.php/Top_10_2010-Main を参照）。一方、既存のCMSを使用する場合、通常はより安全になりますが、一方で、その脆弱性はより広範囲に広がります。
したがって、セキュリティ面では多少のトレードオフですが、よく更新された「標準」のCMSは自家製のものよりも安全ですが、選択する標準のCMSによってある程度異なります。
ただし、「標準」CMSを使用して多くの変更を行うと、アップグレードパスが中断され、CMSを更新できなくなる可能性があるため、脆弱になります。
コアビジネスにこだわるのも、かなり良い議論です。車を作っているからといって、自分で燃料を作る必要があるわけでもありません。それは完全に異なる製品であり、あなたの焦点は別の場所にあるので、誰かがそれをはるかによくする可能性はかなり良いです。新しく開発されたシステムのバグも過小評価しないでください。しばらく経過しているcmsにはいくつかのバグがありますが、新しいものに近い数のバグはありません。既存のcmsは長年にわたって何百万ものユーザーによってテストされてきました。
因数分解する必要があることの1つは、CMSが陳腐化する可能性があることです。必ずしも言語ではなく、機能とデザインが古くなる可能性があります。プログラマーの次のグループは、機能上のこれらの制約に取り組みたくないかもしれませんし、デザインに関しては、彼らのイメージを台無しにするかもしれません！
シンプルなWebサイトの場合、または専念する時間があまりない場合は、CMSが最適です。
独自のCMSを作成する最大の理由は、時間の経過とともに独自の機能を追加できることです。既製のCMSを使用すると、それを作成したサードパーティのアーキテクチャとテクノロジーに縛られます。
例：
Umbraco-レイアウトのXSLTへの依存-#fail
Orchard-Webフォーム開発者のための過剰設計および学習曲線
...等。