0

ページベースではなくアセットベースのアーキテクチャを使用して、楽しみ/個人用のCMSを開発したいのですが(なぜ、この質問の目的ですか)、この件に関する情報はあまり見つかりません。私が見つけたのは、ほとんど表面をこすっただけです (間違った用語で検索している可能性は十分にあります)。

アセットベースの CMS は、アセットと呼ばれるテキストのブロックとして情報を保存します。これらの個々のアセットは相互に関連付けられ、ページが自動的に構築されます。

そのようなシステムの (欠点/) 利点は何ですか?

アセットベースのアーキテクチャの主な原則は何ですか?

「資産」であるべきものとすべきでないものは何ですか? どこでもっと読むことができますか?

4

3 に答える 3

4

私のコメントを残した後、これに答えようとすることにしました:)

「アセット」の定義が「ノード」(Drupal など) またはドキュメント (MongoDB や CouchDB の JSON スタイル ドキュメントなど) に沿っている場合、次のような情報があります。

この記事では「ノード」という用語を使用します。「資産」に最も近く、より一般的に使用されていると思います。これも非常に抽象的な答えかもしれませんが、少なくとも考えさせられ、正しい方向に向けられることを願っています.

ノードベースのアーキテクチャは、ニューラル ネットワーキング パターンとオブジェクト指向プログラミングのクロスとして説明できます。重要なのは、「ノード」はデータのポイントであり、ノードは何らかの方法で相互に接続できるということです。

一部のアーキテクチャでは、ノードをオブジェクト指向クラスのように扱います。このクラスでは、親ノードのさまざまな特性を継承できるノードのさまざまなクラスがあります。すべてのタイプのノードは、その親の基本的なプロパティを継承します。「エッセイ」ノードは、のプロパティを継承する場合があります。ベースノードのプロパティを継承する「Text-Document」ノード。Drupal はこの継承モデルをうまく実装していますが、Facebook の GraphAPI/Open Graph Protocol のような方法でノード間の接続を強調していません。

ノードベースのアーキテクチャのこのパターンは、任意のレベルでも実装でき、自然界に存在します。社会やエコシステム内の社交界を考えてみてください ;) ソフトウェア エンジニアリング レベルでは、MongoDB の単純な方法など、データベースの形をとることができます。データのノード (その場合はドキュメントと呼ばれます) があります。これらのドキュメントは他のドキュメントを参照できますが、Drupal と同様に、Mongo は接続性を強調しません。皮肉なことに、ドキュメント ベースのデータベースとは対照的な MySQL のようなリレーショナル データベースは、実際には接続性をより重視していますが、それについてはまた別の機会に説明します。前述の Facebook の GraphAPI は Web-API レベルで実装されています。オープン グラフ プロトコルがそれを形作っています。繰り返しになりますが、Drupal のようなものはフロントエンド レベルで実装されています (ただし、バックエンドはノード パターンを下位レベルで実装していますが、

最後に、ノードベースのアーキテクチャは、従来のドキュメント/ページ ベースの CMS アーキテクチャよりもはるかに柔軟ですが、開発者側で行うプログラミングと構成がより多くなることも意味します。ノードベースのシステムは、最終的に相互接続がはるかに強くなり、そのコンポーネントはより深いレベルで相互に統合されますが、この深いレベルの接続のために、より壊れやすくなる可能性があります - それは分離よりも少ないです個々のモジュールに。個人的には、人々が 90 年代のように電子雑誌としてではなく、アプリケーションのように Web サイトと対話し始めるにつれて、人々がより「ノードベース」になり、「コンテンツベース」ではなくなるという大きな傾向が見られます。プラス、ユーザーとそのアカウント/プロファイルを Web サイトに追加すると、複雑さが劇的に増加します

「アセット」と言ったのは知っているので、アセットはノード パターンのデータ側をより強調するのに対し、「ノード」はデータ間の接続をより強調すると言います。

しかし、さらに読むために、私が言及したソフトウェアのアーキテクチャを読むことをお勧めします。node.js、JSON、ドキュメント ベースのデータベース、および GraphAPI もチェックしてみてください。これらは、このアセット/ノード ベースのアーキテクチャの考え方にうまく適合しているようです。ウィキペディアにも、これらのパターンに関する優れた情報がいくつかあると確信しています。

于 2011-04-07T23:00:25.213 に答える
0

これは、CakePHP フレームワークを使用して非常に迅速にスケールアップできます。MVC パターンを使用し、レイアウトに挿入できる要素と呼ばれるクラスを提供し、ページ、ユーザー、月齢などに基づいて必要なコンテンツを読み込むことができます。


<page>
 <element calls methodX>
 <element calls methodY>
 <Default Content relies on Controller Action(view/edit/add/custom)>
 <element calls methodZ>
</page>
于 2009-10-20T13:01:01.457 に答える
0

コンテンツ リポジトリによってバックアップされた CMS について説明しているのかもしれません。

リポジトリ自体は、 JSR 170に基づいて Apache Jackrabbit によって実装されます。

API は、コンテンツ リポジトリ内の粒度レベルで双方向にコンテンツにアクセスするための、実装に依存しない標準的な方法である必要があります。コンテンツ リポジトリは、従来のデータ リポジトリのスーパーセットである高レベルの情報管理システムです。コンテンツ リポジトリは、作成者ベースのバージョン管理、全文検索、きめ細かいアクセス制御、コンテンツの分類、コンテンツ イベントの監視などの「コンテンツ サービス」を実装します。コンテンツ リポジトリとデータ リポジトリを区別するのは、これらの「コンテンツ サービス」です。

コンテンツ リポジトリ上で動作する CMS については、Nuxeo を参照してください。

于 2009-10-20T14:22:34.227 に答える