Будущее фреймворка Fusebox

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, возможно, нет причин оставлять его. Это не значит, что вы не должны пробовать все, но нет причин бросать корабль.

Не помешает расширить свой кругозор:

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

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

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

Отсылка к FB, в частности:

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

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

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

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

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

В работе пользуемся Fusebox (php) ... ОТСТОЙ !!!

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

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

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

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

http://www.cfwheels.com

Спустя какое-то время мы можем сказать, что Fusebox скорее мертв, чем жив.

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

2. Статус FuseNG в группах Google.

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

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