Magento - Модуль VS Dataflow - PullRequest
       27

Magento - Модуль VS Dataflow

3 голосов
/ 19 августа 2010

Magento - Модуль VS Dataflow

Я рассматриваю возможность ---- использовать Magento DataFlow для извлечения информации из БД для связи с видео CMS.

Это может спасти разработкувремя - а может и нет.

Это может быть более стабильно - или нет.

Возникает вопрос: лучше ли плотно интегрировать видеосистему в магнито как модуль, который не взламывает ядро ​​---- илизапросить базу данных напрямую - освободить способность работать вне магнитного ядра, но все же взаимодействовать с ним?

Мне нужно решить, лучше ли это с точки зрения разработки и функционального / повседневного использования / обслуживанияточка зрения

-

ОБНОВЛЕНИЕ ОБНОВЛЕНИЯ:

"из вашего поста неясно, где будут находиться эти данные или вы будете записывать в базу данных и т. д."

если это сделано в Magento как модуль, видео и плейлисты будут настроены в admin.

это будет своего рода «медиа-конфигуратор», который может принимать мультипротокольные источники (например, http://erlyvideo.org/files, aws cloudfront, wowza, любой сервер, brightcove, youtube и т. Д.) И выплевывать /настроить блоки кода (например, Flash, HTML5 видео, JS, PHP).это будет сделано путем вставки в код / ​​URL-адреса и / или загрузки контента.

-

, если это не сделано в Magento, то же самое будет происходить в другой CMS (обычай или что-то в этом роде).как Drupal или WordPress)

-

Я не знаю наверняка все возможные взаимодействия, которые должны были бы иметь место, но - в медиа-галерее - есть система избранного, сохраненные сеансы, пользовательгрупповые разрешения, подписка на контент (vod).

отдельные экземпляры видео также будут отображаться на странице магазина и в блоге, но взаимодействие будет ограничено только показом видео.


ОБНОВЛЕНИЕ ВТОРОЕ:

«Какую цель Magento выполняет в этом сценарии?»

Насколько я могу сейчас сказать, сохраненные сеансы (любой пользователь), любимая система(вошедший в систему пользователь), сохраненные настройки (вошедший в систему пользователь), разрешения группы пользователей (любой пользователь или вошедший в систему пользователь + с различными типами пользователей).

Но кроме экземпляров VOD цель галереи мультимедиа:

A.предлагая бесплатные видеоклипы.

B.чтобы пользователи могли видеть трейлеры клиентов на DVD.

Ни один из них, по-видимому, не требует большого взаимодействия.Но ради преемственности может быть лучше сохранить все в одном дб, настроенном от одного администратора, независимо от того, будет ли он более тесно интегрирован по необходимости или для удобства.

Но, как было первоначально заявлено, возможно, что-то более надежное / универсальное или просто более стабильное благодаря своей независимости было бы достижимо за пределами базы данных / хранилища.Может быть, последнее продвигается теми, кто действительно не понимает Magento или имеет некоторые ограничения в своем понимании и, следовательно, советует отделиться.Я не знаю.

-

"Если видео не связаны с продуктами, нет никаких причин для их привязки к продуктам".

Это имеет смысл для трейлеров и бесплатных видео, как только что упомянуто.Я предполагаю, что возможным исключением является видео VOD или группа видео VOD.В таком случае, я полагаю, вы говорите, что для видео может быть лучше, чтобы он был специально настроенным продуктом, который, помимо прочего, также появляется в медиа галерее?

В этом случае VOD, сам видеоклип (или его контейнер) будет продуктом.Его можно предварительно просмотреть, купить и разместить в любом месте по мере необходимости, а также иметь собственную страницу продукта (при необходимости).Как это «сделано» с точки зрения кода - вопрос.

Другой, возможно, другой подход будет выглядеть следующим образом: (страница пропала) http://workbookproject.com/newbreed/2010/06/21/build-your-own-vod-portal/ попробуйте это: http://filmutopia.typepad.com/lone_gun_manifesto/2010/07/how-to-build-your-own-vod-portal-in-a-matter-of-hours-for-less-than-100-lgm.html. Где пользователь фактически покупает доступ к странице.

Зак проделал отличную работу на своем сайте и в статье, и я мог видеть, что такого рода вещи делаются с Magento, но, как отмечает Зак в конце своей статьи, он использует Flash, поэтому мое решение будетпойти дальше и доставить в HTML5 видео и / или [любой протокол].

Так что я не знаю, будет ли Магнето слишком громоздким, чтобы заниматься такими вещами VS, используя WP, как это делал Зак, или что-то еще.

-

"В Magento можно создавать обычные модели данных, чтобы обернуть вызовы базы данных, и, если нет взаимодействия между видео и продуктами, создание одной из этих моделей должноуловка более понятна. "

Хорошо. Я прочитал о" моделях данных в Magento ", но я не вижу, из чего они состоят / физически состоят - в схеме этой спецификации.

Очевидно много способов сделать что-то в Magento.

DataFlow, модели данных, модули Magento ... черт ... почему бы не бросить в виджеты ??:)

-

Еще есть мнение по этому поводу?очень признателен.

Ответы [ 3 ]

1 голос
/ 19 августа 2010

По большей части пребывание внутри фреймворка (в отличие от взлома БД) - ваш лучший выбор с точки зрения головной боли.Если вы можете, создайте модуль, который будет обрабатывать взаимодействие и потреблять его по своему усмотрению (из вашего поста неясно, где будут находиться эти данные или вы пишете в базу данных и т. Д.).

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

Надеюсь, это поможет!

Спасибо, Джо


Игнорированиедругие функции (такие как комментарии, избранное и т. д. просматривают учебные пособия Alan Storm по сохранению данных в базе данных для них), сохраняя видео в виде продуктов, могут быть выполнены с использованием самих атрибутов, и в этом случае все данные могут оставаться в Magento (сохраняютсяАдминистратор, отображается на веб-интерфейсе).Таким образом, объект каталога будет связываться с базой данных для вас, избавляя вас от многих трудностей.

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


На самом деле, я немного об этом рассуждаю.Какую цель Magento служит в этом сценарии?Если видео не относятся к продуктам, нет причин отмечать их продуктами.В Magento можно создавать обычные модели данных, чтобы обернуть вызовы базы данных, и, если нет взаимодействия между видео и продуктами, создание одной из этих моделей должно сделать более аккуратно.

1 голос
/ 23 августа 2010

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

Запись непосредственно в базу данных обойдёт всю встроенную логику бизнес-уровня и уровня данных, которая существует в Magento по уважительным причинам - например, обновление индексов для производительности, проверка ACL и т. д. Поэтому вы должны использовать подход Mage :: getModel ('module / model') для вашей разработки. Он также предоставит вам множество удобных методов для выбора, фильтрации и управления объектами.

Если вы напишите свой собственный модуль, вы сможете лучше понять, что происходит, отладить свой код и наблюдать за последствиями изменений. Использование moduleCreator поможет вам в этом.

Когда вы пишете свой модуль, я предлагаю вам следовать предложению Джозефа, чтобы добавить вашу информацию в качестве атрибутов к связанным продуктам. Это сообщение в блоге проведет вас через процесс.

Удачи! JD

1 голос
/ 19 августа 2010

Я не уверен, что Dataflow - это ответ. Dataflow больше похож на импорт / экспорт cron, который отлично подходит для массовых обновлений, экспорта в нечто вроде ERP и т. Д. - если вы ищете живые данные, вам нужно подключиться к API и извлекать необходимую информацию, которая кажется гораздо более практичной, и в режиме реального времени. Ваши временные вложения не так уж и смешны с точки зрения времени разработки.

...