Magento - Модуль VS Dataflow

Magento - Модуль VS Dataflow

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

Это могло сэкономить время разработки, а могло и нет.

Он мог быть более стабильным, а может и нет.

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

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

--

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

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

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

это будет своего рода «медиа-конфигуратор», который может принимать многопротокольные источники (например, http://erlyvideo.org/files, aws cloudfront, wowza, любой сервер, brightcove, youtube и т. д.) и выводить / настраивать блоки кода (например, flash, html5 video, js, php). это будет сделано путем вставки кода / URL-адресов и / или загрузки содержимого.

--

если это не сделано в Magento, то же самое произойдет и в другой CMS (custom или что-то вроде drupal или wordpress)

--

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

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


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

«Какой цели служит Magento в этом сценарии?»

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

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

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

Б. позволить пользователям видеть трейлеры DVD-продуктов клиентов.

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

Но, как было заявлено изначально, возможно, что-то более надежное / универсальное или просто более стабильное благодаря своей независимости будет доступно за пределами db / store. Возможно, последнее продвигается теми, кто действительно не понимает 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 Video и / или [любой протокол].

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

--

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

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

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

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

--

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


person jon    schedule 19.08.2010    source источник


Ответы (3)


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

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

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

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

Удачи! JD

person Jonathan Day    schedule 22.08.2010
comment
отличные моменты и имеет смысл. Интересно, как изменится это мышление, если подбросить эти аргументы. 1. Создание высокоинтегрированных решений потребует большего обслуживания, потому что они будут ломать и ломать magento при каждом обновлении. 2. Поскольку необходимо учитывать мобильные версии сайта, при использовании чего-то вроде Sencha Touch для создания веб-приложения сайта будет ли проще / лучше в целом кормить ST из полного и полного Magento (с предложенными модулями) или сохранить независимая CMS, которая взаимодействует с веб-приложением ST и Magneto. - person jon; 24.08.2010
comment
Хорошие вопросы. 1. Модульная система Magento в значительной степени отделена, так что это снизит риск поломки из-за обновлений, и я бы предположил, что DataFlow с большей вероятностью будет вносить изменения с меньшим вниманием к обратной совместимости. Команда Varien / Magento не ожидала, что разработчики повесят на DataFlow функциональность, ориентированную на клиентов. 2. У меня нет опыта работы с Sencha Touch (кстати, выглядит неплохо), но в целом, чем меньше движущихся частей в такой интеграции, тем лучше. Я бы порекомендовал использовать Magento в качестве вашей CMS, если вы можете. - person Jonathan Day; 25.08.2010
comment
с Magento в качестве CMS есть мысли о том, как лучше всего передавать данные в ST из магнето? вопрос был задан команде ST, и они сказали: sencha .com / forum / showthread.php? 107792-Plays-well-with-others - person jon; 25.08.2010
comment
Ха, похоже, вам нужен REST-сервер для Magento. Я собираюсь начать новый проект, чтобы создать именно это. В настоящее время внешний API доступен только через SOAP (и довольно медленный и содержит ошибки во всех отчетах), однако интерфейсы AMF (с использованием Zend_AMF) были созданы ранее. Сериализация REST как JSON довольно тривиальна, поскольку доступны библиотеки перевода, но создание обширной реализации REST, ориентированной на клиента, - это большая работа. Вы фактически переписываете весь код из app/design/frontend/ phtmls для вывода XML, а не XHTML. Сделай глубокий вдох! - person Jonathan Day; 26.08.2010
comment
знаете ли вы о каких-либо сайтах, на которых это уже есть (или что-то подобное) - person jon; 30.08.2010
comment
похоже ли это на то, что вы описали с точки зрения методологии интерактивности подключаемого модуля? mysillypointofview.richardferaro.com/2010/05/11/mage-enabler или этот mysillypointofview.richardferaro.com/2010/07/03/ - person jon; 30.08.2010

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

person Nic    schedule 19.08.2010
comment
подключиться к API и извлечь нужную информацию может быть ближе, чем поток данных, поскольку он жив. я посмотрю внимательнее на API - person jon; 20.08.2010

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

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

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

Спасибо, Джо


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

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


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

person Joseph Mastey    schedule 19.08.2010
comment
из вашего сообщения неясно, где эти данные будут в конечном итоге, или пишете ли вы в базу данных и т. д. см. обновление выше - person jon; 20.08.2010
comment
Хранение видео, поскольку продукты могут быть выполнены с использованием самих атрибутов, вы говорите, что каждое видео будет продуктом, и для видео не нужно будет писать дополнительный модуль Magento? - person jon; 20.08.2010
comment
Какой цели служит Magento в этом сценарии? ОБНОВЛЕНИЕ ВТОРОЕ: выше - person jon; 21.08.2010