Будущее Fusebox Framework - PullRequest
       16

Будущее Fusebox Framework

4 голосов
/ 08 февраля 2009

Старый добрый Fusebox был моим первым фреймворком, и он мне все еще очень нравится. Начинается с версии PHP, в настоящее время используется последняя версия CFML.

Но время идет, и я задаюсь вопросом: может быть, мне стоит перейти на другой фреймворк? Ну, я не хочу начинать священную войну здесь. Я просто хочу знать плюсы и минусы продолжения использования FB.

Скажем, я думаю, что контроллеры без XML - это очень хорошая идея и шаг в будущее. Или, может быть, я ошибаюсь, и это не так хорошо, и я должен сосредоточиться на Mach-II или, может быть, Model-Glue или ... (введите свой любимый)?

А как насчет PHP? Кажется, это немного застряло в прошлом. Symfony, CakePHP, Zend и т. Д. Теперь выглядят намного лучше и быстро растут.

Итак, приблизительный список аспектов сравнения следующий:

  1. Время, потраченное на разработку и сопровождение. Для меня FB кажется достаточно хорошим здесь.
  2. ORM интеграция. В настоящее время я использую собственные компоненты (кстати, был удивлен, увидев очень похожий синтаксис в предварительных просмотрах cf9), но беспокоился об их производительности.
  3. Общая производительность приложения. Кэширование? "Разобранные" файлы все еще достаточно хороши?
  4. Интеграция с другими продуктами. Например, с инструментами модульного тестирования - у кого-нибудь есть такой опыт?

Любые мысли и мнения приветствуются. Спасибо.

Ответы [ 6 ]

8 голосов
/ 09 февраля 2009

Fusebox все еще находится в активной разработке и только недавно перешла в другие руки, поэтому ведущий разработчик теперь Адам Хаскелл .

Стоит ли переходить на другую платформу?

Это субъективный вопрос. Единственный хороший ответ заключается в том, что - учитывая бесконечное время и возможности - вы должны попробовать их все и посмотреть, что вы предпочитаете. У всех них есть свои плюсы и минусы, но большинство людей согласны с тем, что речь идет не о структуре , а о - . Вы уже решили, что это инструмент, который вы хотите на своем поясе, так хорошо для вас. Сделайте это инструментом, который вы понимаете и наслаждаетесь.

Тем не менее, время и возможность не всегда доступны. В этом случае вам, вероятно, лучше всего придерживаться того, что вы знаете, и узнавать, что нового с последними изменениями в Fusebox. У меня нет времени, чтобы выучить их всех самостоятельно, поэтому я сам был парнем из модели-клея. В ближайшем будущем я вижу какой-нибудь Fusebox, но, опять же, он субъективен, и важно то, что вы делаете то, что лучше всего работает в вашей ситуации.

PHP

Я не могу говорить о статусе фреймворков PHP, так как я являюсь разработчиком CFML. Опять же, если у вас есть время, поиграйте с ними и оцените, где они находятся и являются ли они инструментом, который вам интересен.

Интеграция ORM

Я знаю, что Model-Glue имеет интеграцию ORM - Reactor и Transfer оба подключаются очень легко. Я подозреваю, что то же самое можно сказать и о Mach-II, и, возможно, Fusebox, но я не уверен в этом.

ColdFusion 9, выпеченный в Hibernate, вероятно, будет хорошо работать в любой среде, но это еще предстоит увидеть.

Производительность / Кэширование; Разобрали файлы?

Это больше вопрос ColdFusion против .Net, верно? PHP также является "разобранным" языком. Предварительно скомпилированный двоичный код всегда будет иметь хотя бы небольшое преимущество во время выполнения, но учтите, что для большинства веб-приложений добавление более мощного оборудования проще и дешевле, чем тратить дополнительные месяцы (или больше) на разработку программного обеспечения.

Достаточно ли хороши "разобранные" файлы? Да! Черт возьми, да!

Интеграция и тестирование

Существует несколько платформ тестирования, в том числе CFUnit, CFCUnit и MXUnit с головы до головы для модульного тестирования (которые хорошо работают для TDD ) и CFSpec для BDD . Я уверен, что есть и другие.

В CF8 появилась интеграция с .Net и Exchange (и, возможно, с некоторыми другими вещами, о которых я забыл), и у нас была интеграция с Java начиная с версии 6. Никогда не было проще «смешать» некоторые написанные компоненты на этих разных языках, чтобы получить лучшее из всех миров.

Заключение

Заголовок вашего вопроса о будущем фреймворка Fusebox, и я могу вам сказать, что он никуда не денется (кроме как продолжать расти и совершенствоваться, как и другие фреймворки CFML ...). Если вы довольны Fusebox, нет причин оставлять его. Это не значит, что вы не должны пробовать все, но нет причин покидать корабль.

3 голосов
/ 09 февраля 2009

Расширить свой кругозор не повредит:

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

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

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

Кивок FB, в частности:

Инфраструктура Fusebox возникла и набрала обороты еще до того, как большинство людей узнали о XML или веб-фреймворках. Это была одна из первых фреймворков для веб-разработки, способных «разорять раздражение», призванных сделать разработку веб-приложений более «веселой» (с целью устранения некоторых неприятностей и утомления из ColdFusion, который сам по себе был исключительной платформой для своего времени) ,

Следовательно, он прошел долгий путь и имеет относительно прочный послужной список (как и ColdFusion).

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

Не называя имен, (вы уже слышали их), я бы посоветовал вам неплохо оставить FB на своем инструментальном поясе, но также перейти в более новые фреймворки, особенно те, которые основаны на языки программирования отличные , кроме PHP и ColdFusion.

Таким образом, вы также расширите свои горизонты и понимание как программиста в целом.

2 голосов
/ 09 февраля 2009

На работе мы используем Fusebox (php) ... ОНО отстой !!

Если это вообще возможно, я бы определенно предложил перенести более "модный" фреймворк.

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

Но я имею в виду .. имея 1 огромный оператор переключения? Разве это не пахнет кодом «это должен быть объект?». Это напоминает мне о процедурной версии класса контроллера RoR. (Я не RoR парень .. просто говорю)

1 голос
/ 19 ноября 2009

Через некоторое время мы можем сказать, что Fusebox больше мертв, чем жив.

  1. Обновление FuseNG от A.Haskell

  2. Состояние FuseNG в группах Google.

1 голос
/ 09 февраля 2009

, если вы ищете все в одной среде типа Rails, посмотрите cfwheels.

http://www.cfwheels.com

0 голосов
/ 19 февраля 2009

Я использовал FB почти исключительно на своей последней работе. Большая часть нашей кодовой базы была не OO (cfc еще не существует), поэтому различие между моделью и представлением действительно помогло нам. Дизайнеры знали, что нужно направляться прямо в папку просмотра и не слишком много копаться в других местах. Схемы дали нам лучший способ отображения областей сайта, чем просто использование каталогов. Вообще это решило много проблем со страницей как конструктивный способ работы.

Со временем я обнаружил, что большая часть кода модели / контроллера заканчивается в cfc и dao только с файлами представления, а индексы действительно остаются в .cfm, так что это разделение происходит почти естественным образом. Это порождает проблему нового типа, с которой FB на самом деле не помогает - управление всеми cfc и получающимися объектами плюс инициализация и наследование. Из-за этого я начал использовать фреймворк coldspring , который гораздо более сфокусирован на тех проблемах, которые возникают в современных OO CF, в отличие от CF на основе страниц, который мы писали несколько лет назад.

...