Я ремонтирую большую CMS, над которой я работаю уже довольно много лет. Сам продукт отличен, но некоторые компоненты, например, базы данных и классы перевода нуждаются в срочной замене – частично самодельные еще в 2002 году, со временем превратились в хаос со временем, и могут возникнуть проблемы с выживанием в аудите безопасности ,
Итак, я внимательно изучил ряд фреймворков (или, точнее, компонентных библиотек, поскольку я не намерен изменять основную структуру CMS), и в итоге мне понравилась Zend Framework. Они предлагают твердую модель MVC, но не вставляют вас в нее, и они предлагают множество профессиональных компонентов, которые, очевидно, получили много внимания (знаете ли вы, что на русском языке имеется множественное множественное число, и вы не можете перевести их, используя простой ($number == 0) or ($number > 1) переключатель? Я этого не сделал, но Zend_Translate может справиться с этим. Чтобы проиллюстрировать уровень толерантности, библиотека, похоже, была построена с помощью.)
Теперь я буквально не нахожусь в обратном направлении, начиная заменять ключевые компоненты системы на Zend-made. У меня на самом деле нет вторых мыслей, и я, разумеется, не собираюсь разжигать пламенную войну, но прежде чем идти дальше, я хотел бы отступить на мгновение и посмотреть, есть ли что-то, что говорит против привязки большой системы к Zend Фреймворк.
Что мне нравится в Zend:
Я думал об инкапсуляции и абстрагировании функциональности ZF в собственные классы, чтобы легче переключаться на фреймворки, но пришел к выводу, что это не будет хорошей идеей, потому что:
поэтому приверженность ZF будет глубокой. Таким образом, мой вопрос:
Есть ли что-то существенное, говорящее о том, чтобы не приступить к Zend Framework?
У вас есть инсайдерское знание о планах Zend Inc. пойти на зло в 2011 году и сделать его закрытой исходной библиотекой? Является ли Zend Inc. управляемым вампирами, управляемыми злыми вампирами, которые хотят захватить Землю? (В комментариях было указано, что Zend фактически управляется вампирами.) Существуют ли концептуальные недостатки в базе кода, которые вы начинаете замечать, когда вы переходите ко всем своим проектам? Является ли появление качественного кода иллюзией? Действительно ли код выглядит неплохо, но он работает очень медленно на чем-нибудь ниже моей четырехъядерной рабочей станции?
Принятие ответа
Большое спасибо всем за вашу подробную обратную связь. Хотел бы я создать щедрость и распределить ее равномерно среди всех ответчиков.
Среди многих мнений, благоприятных для ZF, был один очень хорошо обоснованный. Я воспринял это очень серьезно и внимательно рассмотрел альтернативы, в основном Yii и Kohana. Из этого сравнения и чтения некоторых замечаний относительно ZF и конкурирующих продуктов я вижу, что Zend можно рассматривать как раздутую в некоторых областях по сравнению с более минималистичными структурами. (Я также вижу, что этот «раздувание» в основном имеет серьезные основания для обеспечения максимальной гибкости. Но вопрос о том, нужна ли вам максимальная гибкость и справиться с последующей сложностью или более простой подход с четкими рекомендациями, является допустимым.)
Во всяком случае, я поеду на Zend для проекта, потому что основное использование, которое у меня есть для рамки, есть как библиотека компонентов . Я не хочу использовать модель MVC Zend, мне просто нужны высококачественные компоненты для интернационализации, обработки сеансов и т. Д. Поскольку я создаю распространяемый продукт, мне может быть предложена гибкость Zend (например, поддержка пяти разных форматов словарей). Кроме того, ZF, по-видимому, является единственной структурой, которая допускает степень свободы, которую я хочу (без принудительного использования паттеров, файловых структур …), насколько я вижу, ни одна другая структура не предлагает этого.
Для будущих проектов, в которых я хочу использовать фактические функции MVC, и полностью подчиняюсь соглашениям о структуре приложений, именам, стилям и процедурам, я, возможно, не обязательно буду заниматься Zend, но для более минималистических как Yii или Kohana.
Zend Framework – лучший выбор . Лучший API-интерфейс Framework для всех, читаемый код, языковые соглашения, хорошие документы, общение, поддержка и т. Д.
Мое неприязнь к этому (субъективные, mabe люди собираются понизить меня за это):
Zend_Form , имеет его использование, но в целом слишком навязчивый, я просто хочу структурировать мои HTML не бороться API и декораторов. Zend_Db_Table , мощный, но для выполнения ваших целей требуется большая работа, и Rails научили меня лениться. Нет, я не хочу писать 3 класса для модели, одну для таблицы, одну для набора строк, одну для строки, а затем привязывать их друг к другу и так далее. В какой-то момент мне может понадобиться шлюз данных данных , но на данный момент я действительно хочу связать эти данные с быстрой активной записью . Я очень старался использовать эти два в течение нескольких месяцев, пока, наконец, не получил их.
Я преодолел их (идеи от Ruby on Rails)
echo $this->formText('email', 'you@example.com', array('size' => 32)); РЕДАКТИРОВАТЬ
Есть некоторые новые дети, которые стоит проверить, например, Laravel
Единственное, что ZF действительно выигрывает в других рамках – это маршрутизатор, контроллер и представления, соглашения, чистый читаемый код, процесс.
Если вы не ожидаете масштабного, гигантского проекта с более 20 разработчиками, я бы – если бы вы были вами – делал бы все, включая жертву за руку и / или ногу, чтобы избежать Zend Framework .
Мои два цента действительно сводятся к одному моменту: несмотря на (или, скорее, из-за?), Это поддерживается компанией PHP, она слишком раздута для личного использования и малых и средних проектов.
Моя команда в настоящее время использует Yii для проекта среднего размера. Это тоже не идеально, но удобнее и удобнее для разработчиков по сравнению с старшим братом.
У меня нет большого аргумента против ZF – наоборот; конечно, я еще не использовал все компоненты (не уверен, что кто-то есть) , но я никогда не видел ничего, что выглядело бы «плохо» при просмотре источников.
Когда я начинаю новый проект, я бы вообще пошел с Zend Framework, фактически, если я тот, кто должен выбрать …
Есть хотя бы один аргумент, который я хотел бы добавить в ваш список:
Zend_Db , на мой взгляд! Кроме того, я должен сказать, что я согласен со всеми вашими пунктами.
Об инкапсулировании классов ZF в свои собственные классы: да, вы могли бы это сделать (иногда я это делаю) , но я бы не рекомендовал делать это для всего: в большинстве случаев это, вероятно, не понадобится.
О будущем :
Мы развиваемся с ZF уже почти год, и у меня нет серьезных проблем с этим. Было немного кривой обучения, но как только я понял это, я понял, насколько хорошо это объединяет.
По сравнению с другими структурами некоторые люди могут указать на недостаток библиотеки моделей как недостаток. Я действительно предпочитаю, чтобы мне не говорили, что использовать, и интеграция Доктрины с ZF без трения. Если вы разрабатываете PHP 5.3 и хотите ORM, я бы настоятельно рекомендовал Doctrine 2 (остерегайтесь: он все еще находится в альфа-тестировании).
Другое замечательное – это возможность выбирать и выбирать то, что вы хотите или чего не хотите. Я не большой поклонник Zend_Form, но мне не нужно использовать его, если я этого не хочу. Кроме того, существует очень слабо структурированная архитектура плагинов, которая позволяет вам легко подключить собственные библиотеки к инфраструктуре.
Итак, я довольно большой поклонник этого.
Одна вещь, которую мне не хватает в Zend Framework, – это правильный OR-блок. Zend_DB в порядке, но имеет некоторые недостатки, особенно при работе с огромными базами данных (многие таблицы), это становится очень громоздким. Но есть пара карт OR, которые могут быть интегрированы (например, zend-framework-orm или Doctrine, как упомянуто Паскалем МАРТИНОМ).
Но да, Zend отличная, очень мощная, и я чувствую, что это в какой-то мере то, что PHP на самом деле должно быть / должно было быть с точки зрения интерфейса и функциональности.
Особенно я обожаю очевидную поддержку Dojo для приложений с богатым клиентом и поддержки SOAP .
Я использовал ZF в проекте как единственный разработчик. Хотя кривая обучения была довольно крутой, я не встречал слишком много проблем, описанных выше. В целом я обнаружил, что каркас очень гибкий, а развязка компонентов упростила мою собственную работу, когда способ ZF сделать это не уложил мои потребности.
Но, недавно приступив к использованию python, я бы сказал, используя python;)