Что я теряю, если я использую Wordpress вместо php framework для сложного, но "стандартного" webapp? Стоит ли компромисс?
Я знаю, что это было задано очень много, и я изучил другие ответы, но у меня все еще есть вопросы, поэтому, надеюсь, это проливает свежую информацию о дебатах.
Год назад я создал сервис, планирующий веб-приложение с нуля в CodeIngniter со следующими функциональными возможностями:
- управление пользователями с различными ролями и функциями
- разные серверы для каждого пользователя
- интерактивный и управляемый календарь для служб планирования
- управление и назначение территорий
- управление статусом службы
- отчеты и записи
- выставление счетов с authorize.net
- интерфейсные информационные страницы
Все довольно стандартный материал и codeIgniter отлично поработали. Теперь, через год, я пересматриваю код. Клиент хочет иметь несколько различных функций управления, таких как CMS для страниц, а также добавлять новые службы и изменять расчетные ценовые точки и т.д. Мне нужно добавить новые классы и код, чтобы сделать эту работу.
За последний год я очень глубоко погрузился в Wordpress и понял, что мог бы создать это приложение в Wordpress с использованием пользовательских типов сообщений, таксономий, настраиваемых полей и расширенных пользовательских функций, хотя пользовательский плагин. Во многом это похоже на то, что было бы лучше.
Плюсы использования Wordpress вместо рамки php:
- существующая база с CMS, управление пользователями, знакомый бэкэнд, структура базы данных для начала, экономия времени разработки
- постоянно обновляемая безопасность
- стабильность
- надежность (я знаю, что wordpress может справиться с этим, даже если его предназначение используется для блогов)
Причины использования рамки:
Итак... что лучше? Мне действительно нужен ORM или MVC для этого проекта? Я чувствую, что мои усилия по развитию и клиентский интерфейс будут проще, если я буду использовать Wordpress.
Что еще я потеряю, если переключусь на Wordpress?
Как насчет объединения Wordpress в фреймворке или наоборот? Рекомендации?
Когда имеет смысл использовать фреймворк вместо wordpress?
Ответы
Ответ 1
Это довольно широкий вопрос, поэтому вот довольно широкий ответ...
Wordpress - это CMS. Это хорошая, гибкая CMS с большим количеством встроенной доброты, но ее сладкое пятно управляет сайтом, который в основном касается контента, где контент очень широко определен как "слова, картинки и другие активы". Модель подключаемого модуля позволяет вам создавать/использовать дополнительные функции, а широкое сообщество пользователей обеспечивает большую степень стабильности/безопасности/масштабируемости.
Code Igniter - это структура, предназначенная для функциональных веб-приложений (на практике это обычно означает приложения, управляемые базами данных). Его сладкое пятно управляет сложными взаимодействиями с бизнес-доменом. Это основа для создания любого приложения (в том числе, если вы были обжора для наказания, CMS).
Если ваш бизнес-домен о содержании (и я не думаю, что это так, на основе вашего описания), Wordpress является очевидным победителем. В вашем случае, я думаю, вы, вероятно, могли бы создать решение с помощью Wordpress, но это был бы реальный вопрос - и преимущества, которые вы упомянули о "безопасности, стабильности и надежности", скорее всего, не применимы, потому что вам нужно будет построить много пользовательского кода. Я думаю, вы бы очень быстро добрались до "ну, это не то, как Wordpress хочет, чтобы я работал, но чтобы доставить эту функцию, я просто должен сделать это таким образом".
Когда бизнес-пользователи говорят, что им нужна CMS, они обычно не означают, что они хотят Wordpress (или Drupal, Sitecore или Magnolia); они хотят иметь возможность управлять своим сайтом без необходимости обращаться к техникам. Если ваш сайт в основном основан на базе данных, это означает, что для управления записями базы данных используются экраны.
Ответ 2
Это о структуре и функции на мой взгляд. Как CMS (Wordpress), так и PHP Framework предоставляют структуру/функции для создания собственных функций. Вы можете делать то же самое на CMS и Framework. Они не должны иметь большой разницы в производительности и безопасности среди хорошо известных платформ и CMS.
Однако CMS фокусируется на Front-end (содержимое?), предоставляет готовые к использованию CSS, Javascript (Front-end) для быстрого и быстрого создания веб-сайтов и веб-приложений. Хотя, он не очень ясен по структуре по сравнению с моделью MVC.
Оба будут выполнять ту же работу, если вы будете развиваться самостоятельно, но в команде, каркас может обеспечить выгоду.
Это только мой взгляд, я много использую Wordpress и немного знаю о структуре.
Ответ 3
Я использую CodeIgniter, и мое смещение для этого связано с тем, что вы уже создали основную часть своего приложения в нем и потому что он кажется более гибким/менее предварительно настроенным, чем Wordpress. Я также чувствую, что CI растет в использовании по сравнению с WP с разработчиками, поэтому CI, кажется, более надежна в будущем, хотя, честно говоря, они оба популярны.
Можете ли вы объяснить, что вы боссы? То, как я читаю то, что вы говорите, - это то, что вы 80% времени и времени рассматриваете очищение (или, по крайней мере, возможно, сильно пересматриваете), что 80%, потому что другие 20% кажутся более логически выполненными в Wordpress.
Поскольку я больше изучаю PHP, я нахожу себя использующим еще меньше CI и пишу более прямо PHP или фактически JavaScript (для еще лучшего UX). Поэтому я, наверное, удивляюсь, что кто-то хочет переключиться с минимальной структуры PHP/Ruby/Python на более тяжелую, так как большая часть работы в настоящее время переходит на JavaScript.
Еще один ключевой момент для перехода к прямому PHP заключается в том, что число людей, знающих PHP, затмевает количество людей, знакомых с синтаксисом CI- или WP-специфики. Таким образом, вы с большей вероятностью получите помощь/сотрудничество или карьерный рост, сосредоточившись на прочной основе на "родном языке" над этими диалектами меньшинства. Выполнение этого с помощью PHP также помогает мне лучше понимать другие языки, такие как JavaScript, поскольку уровень абстракции находится на одной странице с php-ruby-python, тогда как структура полностью отличается (в моем увеличенном виде, посторонний) словарь.
