Какую платформу (платформы) Вы предложили бы для сильной, расширяемой dev платформы? [закрытый]
Мы реализовали некоторый код обработки изображений, подобный тому, что Вы описываете, но на массиве байтов В SSE. Ускорение по сравнению с кодом C значительно, в зависимости от точного алгоритма больше, чем фактор 4, даже относительно компилятора Intel. Однако, поскольку Вы уже упомянули, что у Вас есть следующие недостатки:
-
Мобильность. Код будет работать на каждом подобном Intel ЦП, так также AMD, но не на других центральных процессорах. Это не проблема для нас, потому что мы управляем целевыми аппаратными средствами. Переключение компиляторов и даже к ОС на 64 бита может также быть проблемой.
-
у Вас есть крутая кривая обучения, но я нашел, что после схватывания, принципы, пишущий новые алгоритмы не являются этим трудно.
-
Пригодность для обслуживания. Большая часть C или программисты на C++ не знают о блоке/SSE.
Мой совет Вам будет состоять в том, чтобы пойти для него, только если Вам действительно нужно повышение производительности, и Вы не можете найти функцию для своей проблемы в библиотеке как Intel IPP, и если можно жить с проблемами мобильности.
6 ответов
После некоторых исследований я решил перейти на Symfony. Вот мои причины:
- Менее подробный, чем ZF
- Кажется очень настраиваемым из-за использования файлов YAML (но я никогда не чувствую себя перегруженным ими)
- Автозагрузка пользовательских классов не требует дополнительной работы, как в ZF (хотя ее нетрудно настроить в ZF)
- Панель инструментов разработчика отличная, и в версии 1.3 они добавляют к ней некоторые полезные функции.
- Возможность использовать части из других фреймворков (ZF, eZComponents) делает я уверен, что у меня не возникнет проблем с поиском того, что мне нужно.
- Поставляется в комплекте с Doctrine и очень проста в настройке (фактически Doctrine станет ORM по умолчанию в версии 1.3)
- Похоже, есть много более крупное сообщество для Symfony. Google "учебники по symfony" и "учебники по zend framework"
- Yahoo! использовал его для нескольких собственных проектов - приятно видеть большое имя обратно в фреймворк. IMHO
Edit: Надеюсь, чтобы помочь другим в той же ситуации, вот некоторые вещи, которые мне не нравятся в Symfony :
- Не соответствует схеме именования PEAR (ZF)
- Внутренние классы начинаются с «sf». Это противоречит практике написания первой буквы имени класса с большой буквы
- Переменные и функции написаны_like_this, но методы классов имеют верблюжий регистр - мне это кажется небрежным
Это все косметические проблемы; вещи, которые меня беспокоят, потому что мне нравится делать вещи по-своему . Я понимаю, что всякий раз, когда вы используете стороннее программное обеспечение, вы должны быть готовы пойти на некоторые жертвы.
ZF, безусловно, хороший фреймворк, но я считаю, что использование Symfony в качестве основного фреймворка и расширение его частями ZF - лучший выбор для меня и моей команды.
Править
Прошло 2 года с момента первоначальной публикации. это, и поскольку он все еще получает хиты, я подумал, что дам быстрое обновление. Я, вероятно, построил около 25-30 проектов с использованием symfony 1.x за последние 2 года, и я м очень доволен тем, как он выполнен. Как полнофункциональный MVC-фреймворк в партнерстве с Doctrine, он обрабатывал почти все, что я ему предлагал. И с чем бы он ни не справился, легко было добавить свой собственный код. На самом деле, это то, что мне больше всего нравится в Symfony - насколько легко ее расширять. В итоге я создал кучу плагинов и поведений Doctrine, которые значительно сократили время разработки. И инструменты генератора админки были подарком богу. Я все еще использую Symfony 1.4 для нескольких проектов, но решил сосредоточиться сейчас на использовании Symfony2. Это совершенно другой зверь, чем symfony 1, но я очень ценю его архитектуру. Что еще более важно, кажется, что его даже проще расширить, чем symfony 1.x. Мне действительно не хватает некоторых функций 1.x, но это жертва, на которую приходится жертвовать при смене фреймворка.
Как полнофункциональный MVC-фреймворк в партнерстве с Doctrine, он обрабатывал почти все, что я ему предлагал. И с чем бы он ни не справился, легко было добавить свой собственный код. На самом деле, это то, что мне больше всего нравится в Symfony - насколько легко ее расширять. В итоге я создал кучу плагинов и поведений Doctrine, которые значительно сократили время разработки. И инструменты генератора админки были подарком богу. Я все еще использую Symfony 1.4 для нескольких проектов, но решил сосредоточиться на использовании Symfony2. Это совершенно другой зверь, чем symfony 1, но я очень ценю его архитектуру. Что еще более важно, кажется, что его даже проще расширить, чем symfony 1.x. Мне действительно не хватает некоторых функций 1.x, но это жертва, на которую приходится жертвовать при смене фреймворка. Как полнофункциональный MVC-фреймворк в партнерстве с Doctrine, он обрабатывал почти все, что я ему предлагал. И с чем бы он ни не справился, легко было добавить свой собственный код. На самом деле, это то, что мне больше всего нравится в Symfony - насколько легко ее расширять. В итоге я создал кучу плагинов и поведений Doctrine, которые значительно сократили время разработки. И инструменты генератора админки были подарком богу. Я все еще использую Symfony 1.4 для нескольких проектов, но решил сосредоточиться сейчас на использовании Symfony2. Это совершенно другой зверь, чем symfony 1, но я очень ценю его архитектуру. Что еще более важно, кажется, что его даже проще расширить, чем symfony 1.x. Мне действительно не хватает некоторых функций 1.x, но это жертва, на которую приходится жертвовать при смене фреймворка. в партнерстве с Doctrine, она справлялась почти со всем, что я ей предлагал. И с чем бы он ни не справился, было легко добавить свой собственный код. На самом деле, это то, что мне больше всего нравится в Symfony - насколько легко ее расширять. В итоге я создал кучу плагинов и поведений Doctrine, которые значительно сократили время разработки. И инструменты генератора админки были подарком богу. Я все еще использую Symfony 1.4 для нескольких проектов, но решил сосредоточиться сейчас на использовании Symfony2. Это совершенно другой зверь, чем symfony 1, но я очень ценю его архитектуру. Что еще более важно, кажется, что его даже проще расширить, чем symfony 1.x. Я скучаю по некоторым функциям 1.x, но это жертва, которую приходится приносить при смене фреймворка. в партнерстве с Doctrine, она справлялась почти со всем, что я ей предлагал. И с чем бы он ни не справился, было легко добавить свой собственный код. На самом деле, это то, что мне больше всего нравится в Symfony - насколько легко ее расширять. В итоге я создал кучу плагинов и поведений Doctrine, которые значительно сократили время разработки. И инструменты генератора админки были подарком богу. Я все еще использую Symfony 1.4 для нескольких проектов, но решил сосредоточиться сейчас на использовании Symfony2. Это совершенно другой зверь, чем symfony 1, но я очень ценю его архитектуру. Что еще более важно, кажется, что его даже проще расширить, чем symfony 1.x. Я скучаю по некоторым функциям 1.x, но это жертва, которую приходится приносить при смене фреймворка. t, было легко добавить свой собственный код. На самом деле, это то, что мне больше всего нравится в Symfony - насколько легко ее расширять. В итоге я создал кучу плагинов и поведений Doctrine, которые значительно сократили время разработки. И инструменты генератора админки были подарком богу. Я все еще использую Symfony 1.4 для нескольких проектов, но решил сосредоточиться сейчас на использовании Symfony2. Это совершенно другой зверь, чем symfony 1, но я очень ценю его архитектуру. Что еще более важно, кажется, что его даже проще расширить, чем symfony 1.x. Я скучаю по некоторым функциям 1.x, но это жертва, которую приходится приносить при смене фреймворка. t, было легко добавить свой собственный код. На самом деле, это то, что мне больше всего нравится в Symfony - насколько легко ее расширять. В итоге я создал кучу плагинов и поведений Doctrine, которые значительно сократили время разработки. И инструменты генератора админки были подарком богу. Я все еще использую Symfony 1.4 для нескольких проектов, но решил сосредоточиться на использовании Symfony2. Это совершенно другой зверь, чем symfony 1, но я очень ценю его архитектуру. Что еще более важно, кажется, что его даже проще расширить, чем symfony 1.x. Мне действительно не хватает некоторых функций 1.x, но это жертва, которую приходится приносить при смене фреймворка. В итоге я создал кучу плагинов и поведений Doctrine, которые значительно сократили время разработки. И инструменты генератора админки были подарком богу. Я все еще использую Symfony 1.4 для нескольких проектов, но решил сосредоточиться на использовании Symfony2. Это совершенно другой зверь, чем symfony 1, но я очень ценю его архитектуру. Что еще более важно, кажется, что его даже проще расширить, чем symfony 1.x. Мне действительно не хватает некоторых функций 1.x, но это жертва, которую приходится приносить при смене фреймворка. В итоге я создал кучу плагинов и поведений Doctrine, которые значительно сократили время разработки. И инструменты генератора админки были подарком богу. Я все еще использую Symfony 1.4 для нескольких проектов, но решил сосредоточиться на использовании Symfony2. Это совершенно другой зверь, чем symfony 1, но я очень ценю его архитектуру. Что еще более важно, кажется, что его даже проще расширить, чем symfony 1.x. Мне действительно не хватает некоторых функций 1.x, но это жертва, на которую приходится жертвовать при смене фреймворка. но я очень ценю его архитектуру. Что еще более важно, кажется, что его даже проще расширить, чем symfony 1.x. Мне действительно не хватает некоторых функций 1.x, но это жертва, которую приходится приносить при смене фреймворка. но я очень ценю его архитектуру. Что еще более важно, кажется, что его даже проще расширить, чем symfony 1.x. Мне действительно не хватает некоторых функций 1.x, но это жертва, на которую приходится жертвовать при смене фреймворка.*
РЕДАКТИРОВАТЬ: Теперь, когда я почти понимаю, КАК для улучшения ZendFramework с помощью ваш собственный код (как указано здесь Добавление Сторонняя библиотека для Zend и здесь Использование сторонней библиотеки в Zend ), Я снова переключился на ZendFramework. я в настоящее время разрабатываю мое приложение и каждый день, который я работаю и тестирую что угодно с ZendFramework все более и более знакомым и легко ускоряет мое развитие. Мой совет: Используйте ZendFramework.
*
У меня такая же проблема:
Моя история: Я использовал CakePHP, пока не захотел увеличить размер своего проекта. CakePHP оказался не таким гибким, как мне хотелось бы. Поэтому я попытался использовать ZendFramework.
В самый первый раз, когда я прочитал руководство «QuickStart», я немного боялся иметь столько файлов для простого приложения гостевой книги.
После некоторого времени «поиграться» с ZendFramework Я решил использовать ZF в качестве сторонней библиотеки в моей собственной пользовательской среде.
Проблема в том, что если вы используете компоненты Zend MVC, вам может потребоваться 30% всей структуры, потому что компоненты MVC являются одним целым большей части ZF. Я имею в виду, что если я использую такую большую часть фреймворка, ПОЧЕМУ не следует использовать и остальные?
После этого я решил написать свой собственный фреймворк COMPLETE без использования ZendFramework в качестве сторонней библиотеки.
Теперь я сижу перед горами бумаг, полных набросков о разработке кода.
Я буду держать вас в курсе моих дальнейших решений.
Zend Framework: огромный, гибкий, модульный. Я бы использовал его только в том случае, если собираю корпоративную большую ультра систему.
Но я использую Yii Framework , и мне это нравится. Потому что: очень быстро, просто, виджеты (компонент легко повторно использовать, это очень приятно).
Yii проще в использовании, потому что это не корпоративный фреймворк, и в нем есть все базовые функции, которые вам действительно нужны в большинстве случаев.
I честно думаю, это действительно зависит от вашего стиля. На этот вопрос нет конца.
ZF в значительной степени полагается на классические и проверенные принципы проектирования. Он также очень расширяемый, но требует больше «конфигурации», чем «соглашения». Я лично не доверяю стороннему коду по своей природе, поэтому я поклонник более многословия, чтобы лучше познакомиться с технологиями, с которыми я работаю. Но это только я.
Я также успешно использовал CakePHP и два других фреймворка, принадлежащих компании, в которой я работал с большим успехом. Все они пытаются делать похожие вещи, просто выберите то, что вам больше нравится.
Мне нравится использовать ZF из-за строгих соглашений. Вы можете быть уверены, что все будет так, как вы этого ожидаете. Имена классов, имена функций, имена переменных, структура каталогов ... все это. Это действительно ускоряет разработку, если вы ее придерживаетесь. Если вы адаптируете его, это больше похоже на изучение вашего собственного кода при проверке внутренних компонентов ZF;)
Давайте будем честными. ZF не быстрый. Не так быстро, как Nette, CodeIgniter и т.д. Но разница в том, что на все есть свой класс. А если его нет, есть класс, который вы можете расширить, или интерфейс, который вы можете реализовать.
Все остальные фреймворки пытаются добиться эффекта «вау» (блог за 30 секунд, твиттер за 2 часа и т. Д.). Но при разработке реального приложения вы понимаете, что вам нужна гибкая и обширная архитектура по желанию.
Я лично успешно использовал CakePHP как для больших, так и для маленьких проектов, однако часто бывает сложно заставить его сдвинуть с места так, как вы хотите. Мои причины для использования Cake по-прежнему заключаются в том, что поддержка сообщества на высшем уровне, обновления безопасности происходят часто, и они не навязывают вам метапакеты (например, модульное тестирование) (хотя это входит в комплект, вы можете просто bin его, если вы не заинтересованы в использовании встроенного пакета).
В целом, эта система стала для меня хорошей системой за последние несколько месяцев, однако я снова и снова слышал, что Symphony фантастичен, так что, возможно, вы будете в выигрыше со своими первыми мыслями. Поскольку поддержка NetBeans для Symphony находится в стадии разработки, я тоже могу обнаружить необходимость в скором переключении.