Разработка базы данных на основе активов/узлов

Question

Я хотел бы разработать CMS для развлечения/личного использования с использованием архитектуры на основе активов, а не на основе страниц (почему, является целью этого вопроса), но я не могу найти много информацию по этому вопросу. Все, что я нашел, едва царапает поверхность (есть хороший шанс, что я ищу неправильные термины).

Основанная на активах CMS хранит информацию в виде блоков текста, называемых активами. Эти отдельные активы затем связаны с друг с другом, чтобы автоматически создавать страниц.

Каковы преимущества (dis /) такой системы?

Каковы основные принципы архитектуры на основе активов?

Что должно и не должно быть «активом»? Где я могу прочитать больше?

Answer 1

Вы можете очень быстро масштабировать его, используя фреймворк CakePHP. Он использует шаблон MVC и предоставляют классы, называемых элементами, которые могут быть вставлены в макеты и может загружать любой контент, который вы хотите на основе страницы, пользователь, фазах луны и т.д.

---

<page> 
<element calls methodX> 
<element calls methodY> 
<Default Content relies on Controller Action(view/edit/add/custom)> 
<element calls methodZ> 
</page> 

Answer 2

Я думаю, что вы могли бы описывать CMS, поддерживаемую репозиторием контента.

Само хранилище осуществляется Apache Jackrabbit на основе JSR 170:

API-интерфейс должен быть стандартным, внедрение независимой, способ доступа к контенту, двунаправленным на гранулированном уровне в хранилище контента. Репозиторий контента представляет собой высокоуровневую систему управления информацией, которая является надмножеством традиционных репозиториев данных. Репозиторий контента реализует «сервисы контента», такие как: авторское управление версиями, полный текстовый поиск, мелкозернистый контроль доступа, категоризация контента и мониторинг событий контента. Именно эти «контент-сервисы» различают репозиторий контента из хранилища данных.

Для CMS, работающего над хранилищем контента, посмотрите на Nuxeo.

Answer 3

Решил попробовать ответить на этот вопрос после того, как оставить свой комментарий :)

Если ваше определение «актива» вдоль линии «узел» (например, как в Drupal), или документ (например, JSON-документы в MongoDB или CouchDB), то вот некоторая информация:

Я буду использовать термин «узел» для этого сообщения. Я думаю, что он ближе всего к «активному» и более широко используется. Это также может быть очень абстрактным ответом, но, надеюсь, он по крайней мере заставит вас думать и указывать в правильном направлении.

Архитектура, основанная на узлах, может быть описана как крест между схемами нейронных сетей и объектно-ориентированным программированием. Ключ состоит в том, что «узлы» являются точками данных, а узлы могут быть связаны друг с другом каким-либо образом.

Некоторые архитектуры будут обрабатывать узлы, как объектно-ориентированные классы, где у вас есть разные классы узлов, которые могут наследовать различные характеристики родительских узлов - каждый тип узла наследует основные свойства его родителя - узел «Эссе» может наследует свойства узла «Text-Document», который, в свою очередь, наследует свойства базового узла.Drupal хорошо реализует эту модель наследования, хотя она не подчеркивает связи между узлами так, как это делает приложение GraphAPI/Open Graph Protocol от Facebook.

Этот шаблон архитектуры на основе узлов может быть реализован на любом уровне и существует в природе - думать о социальных кругах внутри общества или экосистем;) На уровне разработки программного обеспечения он может принимать форму базы данных, такой как как MongoDB просто имеет узлы данных (которые в этом случае называются документами). Эти документы могут ссылаться на другие документы, хотя, как и Друпал, Монго не подчеркивает связности. Как ни странно, реляционные базы данных, такие как MySQL, которые противоположны базам данных на основе документов, на самом деле подчеркивают связанность больше, но это обсуждение еще на один день. Facebook GraphAPI, который я упомянул выше, реализован на уровне Web-API. Протокол Open Graph формирует его. И опять-таки, что-то вроде Drupal реализовано на уровне переднего плана (хотя, конечно же, его back-end реализует шаблон узла на более низком уровне).

Наконец, архитектура на основе узлов гораздо более гибкая, чем традиционная архитектура CMS на основе документов/страниц, но это также означает, что на стороне разработчиков требуется гораздо больше программирования и настройки. Узел-система в конечном итоге будет гораздо более взаимосвязана, и ее компоненты будут интегрированы с одним другим более глубоким уровнем, но также может быть более восприимчивым к взлому из-за этого глубокого уровня соединения - он меньше, чем разделенный в отдельные модули. Лично я вижу огромную тенденцию, когда люди движутся, чтобы стать более «основанными на узлах» и менее «основанными на контенте», поскольку люди начинают взаимодействовать с сайтами, более похожими на приложения, чем на электронные журналы, как в 90-х годах. Кроме того, шаблон узла хорошо сочетается с акцентом на пользовательский вклад и социальный просмотр, поскольку добавление людей и их учетных записей/профилей на веб-сайт значительно увеличивает сложность.

Я знаю, что вы сказали «актив», поэтому я также скажу, что актив больше подчеркивает сторону данных шаблона узла, тогда как «узел» больше подчеркивает связи между частями данных.

Но для дальнейшего чтения я бы рекомендовал ознакомиться с архитектурой программного обеспечения, о котором я упоминал. Вы также можете проверить узлы node.js, JSON и базы данных на основе документов и GraphAPI, поскольку они, похоже, хорошо сочетаются с этой идеей архитектуры активов/узлов. Я уверен, что у Википедии есть хорошие вещи на этих моделях.