Будущее каркаса Fusebox
Старый добрый Fusebox был моим первым фреймворком, и он мне до сих пор очень нравится. Начал с версии PHP, в настоящее время использует последнюю версию CFML.
Но время идет, и я задаюсь вопросом: может быть, мне следует переключиться на другой фреймворк? Что ж, я не хочу начинать здесь священную войну. Я просто хочу знать плюсы и минусы продолжения использования FB.
Скажите, я думаю, что контроллеры без XML - это очень хорошая идея и шаг в будущее. Или, может быть, я ошибаюсь, и это не энох, и я должен сконцентрируйтесь на Mach-II или, может быть, на Клеевой модели или... (введите свой любимый)?
Но как насчет PHP? Кажется, что это немного застряло в прошлом. Symfony, CakePHP, Zend и т.д. Сейчас выглядят намного лучше и быстро растут.
Итак, примерный список аспектов сравнения выглядит следующим образом:
- Время, затраченное на разработку и техническое обслуживание. Для меня FB здесь кажется достаточно хорошим.
- Интеграция ORM. В настоящее время я использую собственные компоненты (кстати, был удивлен, увидев очень похожий синтаксис в cf9 предварительные просмотры), но у них есть опасения по поводу их производительности.
- Общая производительность приложения. Кэширование? "Проанализированные" файлы все еще достаточно хороши?
- Интеграция с другими продуктами. Например, с помощью инструментов модульного тестирования - у кого-нибудь есть опыт в этом?
Любые мысли и мнения приветствуются. Спасибо.
6 answers
Fusebox все еще находится в стадии активной разработки и совсем недавно перешел из рук в руки, поэтому ведущим разработчиком теперь является Адам Хаскелл.
Следует ли вам переключиться на другой фреймворк?
Это субъективный вопрос. Единственный хороший ответ заключается в том, что - учитывая бесконечное время и возможности - вы должны попробовать их все и посмотреть, что вы предпочитаете. У всех них есть свои плюсы и минусы, но большинство людей согласны с тем, что вопрос не в том, какая структура, а в том, к структуре. Вы уже решили, что это инструмент, который вы хотите носить на поясе, так хорошо для вас. Сделайте это инструментом, который вы понимаете и которым наслаждаетесь.
Тем не менее, время и возможности не всегда доступны. В этом случае вам, вероятно, лучше придерживаться того, что вы знаете, и изучать, что нового с последними изменениями в Fusebox. У меня нет времени изучать их все самостоятельно, поэтому я сам был парнем, который Клеил модели. Я вижу какой-то предохранитель в моем ближайшем будущем, но опять же, это субъективно и важно то, что вы делаете то, что лучше всего работает в вашей ситуации.
PHP
Я действительно не могу говорить о статусе фреймворков PHP, так как я разработчик CFML. Опять же, если у вас есть время, поиграйте с ними и оцените, где они находятся и являются ли они инструментом, который вам интересен.
Интеграция ORM
Я знаю, что модель-Клей имеет интеграцию ORM - Реактор и Передача оба подключаются очень легко. Я подозреваю, что то же самое может быть сказано для Mach-II и, возможно, для Fusebox, но я не уверен ни в том, ни в другом.
ColdFusion 9, запеченный в спящем режиме, вероятно, будет хорошо работать в любой среде, но это еще предстоит выяснить.
Производительность/Кэширование; Проанализированные файлы?
Это больше похоже на холодное слияние по сравнению с Вопрос .Net, верно? PHP также является "анализируемым" языком. Предварительно скомпилированный двоичный код всегда будет иметь по крайней мере небольшое преимущество во время выполнения, но учтите, что для большинства веб-приложений добавление некоторых дополнительных способное оборудование проще и дешевле, чем тратить дополнительные несколько месяцев (или больше) на разработку программного обеспечения.
Достаточно ли хороши "проанализированные" файлы? Да! Черт возьми, да!
Платформы интеграции и тестирования
Существует несколько платформ тестирования, включая CFUNIT, CFCUnit и MXUnit, которые мне нравятся для модульного тестирования (которые хорошо работают для TDD) и CFSPEC для BDD. Я уверен, что есть и много других.
CF8 принесла интеграцию с.Net и Exchange (и, возможно, еще несколько вещей, которые я забыл), и у нас была интеграция с Java начиная с версии 6. Никогда не было проще "смешать" некоторые компоненты, написанные на этих разных языках, чтобы получить лучшее из всех миров.
Заключение
Название вашего вопроса касается будущего фреймворка Fusebox, и я могу сказать вам, что он никуда не денется (кроме как продолжать расти и совершенствоваться, как и другие CFML рамки...). Если вы довольны Fusebox, возможно, нет причин оставлять его. Это не значит, что вы не должны пробовать все, но нет причин покидать корабль.
Это не повредит расширить свой кругозор:
Диапазон сравнения настолько широк, что вы не сможете получить исчерпывающий и точно подобранный ответ на ваши четыре критерия в одном потоке SO. Это хороший вопрос, но на него нет однозначного ответа.
Вместо этого я бы спросил, что (если что-нибудь) помешает вам попробовать другую структуру и расширить свои горизонты (при условии, что ваш эксклюзивный или основной опыт был связан с FB).
Ничто не превзойдет вашу собственную оценку ваших четырех критериев, основанную на личном опыте, особенно с учетом того, что вы спрашиваете о факторах, которые либо очень субъективны, либо разумно рассматриваются каждой "высокопрофессиональной" платформой веб-приложений.
Кивок в сторону FB, в частности:
Фреймворк Fusebox возник и набрал обороты еще до того, как большинство людей услышали о XML или веб-фреймворках. Это была одна из первых "раздражающих" веб-разработок фреймворки, разработанные для того, чтобы на самом деле сделать разработку веб-приложений более "увлекательной" (с целью устранения некоторых неприятностей и скуки от ColdFusion, который сам по себе был исключительным фреймворком для своего времени).
Следовательно, он прошел долгий путь и имеет относительно солидный послужной список (как и ColdFusion).
Однако некоторые могут счесть это значительным ущербом для FB (так же, как и для ColdFusion). В рамках есть много "багажа", который довольно честно говоря, его бы там не было, если бы он был того же возраста, что и многие другие фреймворки MVC, которые завоевывают доверие как "новые дети" в квартале. Есть много аспектов, которые (с точки зрения языкового дизайна) выявляют некоторые грубые грани, которые могут негативно повлиять на ваше представление о фреймворках веб-приложений, если вы выберете FB в качестве своего эксклюзивного способа выполнения задач.
Не называя имен, (вы их уже слышали) Я бы посоветовал вам сделать все возможное, чтобы сохранить FB на своем пояс инструментов, но также разветвляется на более новые фреймворки, особенно те, которые основаны на языках программирования , отличных от PHP и ColdFusion.
Таким образом, вы также расширите свой кругозор и понимание как программист в целом.
На работе мы используем Fusebox (php)... ЭТО ОТСТОЙ!!
Если это вообще возможно, я бы определенно предложил перенести более "модную" структуру.
Хотя.. То, что я делаю, и это, похоже, устраняет большую часть моих разногласий с фреймворком, заключается в написании файлов шаблонов, включении их из коммутатора, а также вычислении любых параметров "времени выполнения" внутри того же оператора case. Это способствует хорошему повторному использованию кода.
Но я имею в виду.. имея 1 огромное заявление о переключении? Разве это не код запах для "это должен быть объект?". Это напоминает мне процедурную версию класса контроллера RoR. (Я не парень из RoR.. просто говорю)
Если вы ищете фреймворк типа "все в одном", ознакомьтесь с cfwheels.
Через некоторое время мы можем сказать, что Fusebox скорее мертв, чем жив.
Обновление Fuseng от А.Хаскелла
Статус FuseNG в группах Google.
Я использовал FB почти исключительно на своей последней работе. Большая часть нашей кодовой базы не была OO (cfc еще не существовали), поэтому различие между моделью и представлением действительно помогло нам. Дизайнеры знали, что нужно сразу перейти к папке просмотра и не слишком много копаться в других местах. Схемы дали нам лучший способ отображения областей сайта, чем просто использование каталогов. Как правило, это решало множество проблем со страницей как способом построения работы.
Со временем я обнаружил, что большая часть кода модели/контроллера заканчивается в cfc и dao только файлами просмотра, а индексы действительно остаются в .cfm, так что это разделение происходит почти естественно. Это порождает проблему нового типа, с которой FB на самом деле не помогает - управление всеми объектами cfc и результирующими объектами, а также инициализация и наследование. Из-за этого я начал использовать фреймворк coldspring, который гораздо больше ориентирован на проблемы, возникающие в современном OO CF, в приложении к основанному на странице CF, которым мы были писал много лет назад.