Когато за пръв път се сблъсках със Zend Framework бях заслепен от високото ниво на абстракция, изчистения код и богатата библиотека. Тогава бях на 18 години, а познанията ми по ООП бяха ограничени до разработване на семпли сайтове, използващи 2-3 класа + Smarty. На теория знаех всичко за ООП, но концептуално нямах идея как да се възползвам от силата на тази технология, просто бях чувал, че да използваш класове и обекти е готино. Zend Framework изигра главна роля в професионалното ми развитие, и успя да пречупи мирогледа ми, превръщайки тогаващата представа за програмирането в нещо много по-различно. Zend Framework ме научи да мисля обектно.

Илюзията на всеки програмист, който знае ООП на теория(но не познава design pattern-и например), е че той няма нужда от приети в общността похвати, той е велик и няма защо да се учи от някой. Това срещам във почти всеки PHP програмист в днешно време. Преди да се сблъскам със ZF, аз също бях един твърдоглав начинаещ.

Нека опиша един проект, който не използва фреймуърк: разполага с един клас, който често се казва Main или Core, а в него се съдържат методи от връзка с база данни до извличане на информация за продукти, та чак до потребителска регистрация. Това е корабът Майка. Често се случва корабът Майка да достигне над 10 000 реда код, което е голяма гордост за автора. Някои програмисти си мерят… редовете код, но в сорс кода количество != качество.

Преминаването от този стар стил към обектно-ориентирано мислене е много труден (това че ползваш два-три класа не значи, че проекта ти е обектно-ориентиран, а по-скоро обектно-дезориентиран).

Когато преди година разбрах, че се готви нова версия на любимата ми платформата, бях повече от сигурен, че ще има куп нови неща за учене и имах чувството, че Zend ще промени света на PHP за втори път.

Какво не беше наред със Zend Framework 1?

Въпреки, че храня доста сантиментални чувства към ZF, не мога да пренебрегна факта, че има много неща, които не ми харесват.

Тромава модулна система

Модулната система в Zend Framework беше добавена по-късно. В по-ранните версии на ZF не беше обърнато внимание на модулите и затова възможността за модули в ZF 1 e по-скоро нагодена. Липсват много важни възможности като модулна конфигурация и конфигуриран лоудър за класове. Всички тези неща бяха не чак толкова трудно поправими, но създадоха нерви.

Прекалено много Сингълтон

Един от най-често срещаните шаблони в платформата е Singleton. Но защо Сингълтон е лош? Той е толкова лесен за импелентация и използване. Истината е, че времето на сингълтоните мина и ние трябва плавно да забравим за тях.

Защо Сингълтон е лош?

Да вземем например Zend_Controller_Front – гръбнака на MVC имплементацията в Zend. Този клас предоставя единствен обект в цялото приложение чрез метода getInstance(). Извиква се лесно от всички крайща на кода. Благодарение на това ние можем да получим информация за текущата http заявка както и много други ценни параметри, които той съхранява. Но какво правим, ако искаме да сменим Zend_Controller_Front с наша собствена имплементация на класа? Това е напълно невъзможно, защото останалите класове в библиотеката Zend_Controller използват този сингълтон и няма чист начин да променим това. Те винаги ще ползват този клас. Не можем да редактираме останалите класове в пакета, защото трябва да правим това всеки път когато излезе нова версия на Zend Framework 1.*.

Освен сингълтоните, лоши са всички други класове, предоставящи статични методи с важна имплементация, като например Zend_Controller_Action_HelperBroker –  той също се извиква статично от много места и не можем да го сменим с наш клас.

Някои ограничения на Zend_Db

Един от най-любимите ми компоненти в Zend e Zend_Db.

Zend_Db е добре измислен абстрактен слой, чиято цел е да облече SQL заявките в обектно-ориентирани дрехи. В структурата на компонента са използвани шаблони от Patterns of Enterprise Application Architecture като Table Data Gateway и Row Data Gateway. Използването на Zend_Db е истинско удоволствие. За един проект със средна сложност, Zend_Db може да осигури функционалност без да има нужда да се пише нито една SQL заявка.

Какво не е наред със Zend_Db?

Много е трудно да се критикува толкова мощен инструмент, но съм се сблъсквал с някои малки ограничения на компонента.

Класът Zend_Db_Adapter осигурява 4-те стандартни CRUD метода insert(), update(), delete() и select(), с чиято помощ може лесно да боравите със съответните SQL команди, но това което ограничава функциалността на този клас е, че не можете лесно да обогатите функциалността на някой от тези методи.

Да вземем например insert(). С този метод се създава заявка INSERT INTO .. VALUES .., но ако искам да добавя ключовата дума IGNORE (която ще репресира грешки предизвикани от дублаж на редове с уникални ключове) ще ударя на камък, защото такава настройка в Zend_Db не съществува. В случея лошото е, не че няма INSERT IGNORE заявки, а че не мога лесно да променя Zend_Db, така че да добавя тази функционалност.

Същата ситуация е и с INSERT .. ON DUPLICATE KEY UPDATE.

Ново начало за Zend Framework

Една от главните цели на първата версия на ZF беше да стандартизира употребата на PHP като се лансират новите възможности на 5-та версия. Минаха години от първия релийз на фреймуърка и PHP също се промени. Много от възможностите, планувани за дългоочакваната версия 6 бяха пуснати предварително във феноменалната 5.3.

Наистина езикът се изкачи на още по-високо ниво, приличайки на големия брат Java. Запознахме се с namespace-ове, callback функции, и още други интересни възможности се появиха в следващата версия – PHP 5.4.

С напредването на времето в общността се усети нуждата от примерна и стабилна имплементация на всички тези възможности и следваща мажорна версия на ZF беше неизбежна. Дълго се дискутираха идеи относно бъдещето на новия фреймуърк, но като че ли цялата енергия беше концентрирана около Dependency Injection.

Темата не засяга обучение върху основите на Zend Framework 2, а по-скоро пропаганда. Затова няма да видите конкретни примери за употреба и т.н.

Dependency Injection

Да, Zend Framework 2 трябваше да бъде Dependency Injection базиран. Но защо? Какво ще ни даде това така далечно и неясно понятие?

Всъщност приобщаването на DI в PHP общността беше една сериозна крачка напред.

Повече за DI тук

Гъвкавата архитектура

Най-важната екстра, която дава новата архитектура на ZF 2, е че с използването на Dependency Injection можем да сменим всеки клас в библиотеката с наша собствена имплементация. Лансирано е използването на интерфейси, а за сингълтони не става и дума.

Мощна конфигурация

Подмяната на класове става посредством специални настройки в така наречената DI конфигурация. Няма да давам конкретни примери, защото целта на статията е да обобщя на кратко възможностите на Zend Framework 2.

Имплементация на Service Locator

[TBS_ALERT]   Само за разбирачи[/TBS_ALERT]

Комбинацията между Dependency Injection и Service Locator е като да правиш любов с много красива и нежна жена. Ако приемем, че Dependency Injection е силна, но груба страст, то Service Locator добавя нежност и красота.

Когато зависимостите в системата ни са много и всички те се инжектират посредством DI контейнер, то има много случеи, когато обекти ще бъдат инжектирани напразно, което би се отразило на производителността.

Service Locator-ите решават този проблем като предоставят инстанциите само когато има нужда от тях. Въпреки, че това е напълно различен патърн, той може да бъде използван много хармонично заедно с DI (което е широка практика). Резултатът е инжектиране не на конкретни инстанции, а на самия Service Locator, чрез който се осъществява достъп до нужните услуги/инстанции.

Въпреки, че DI е в сърцето на Zend Framework 2, разработчиците си нямат взимане-даване директно с DI конфигурацията на контейнера. Самият DI слой е скрит под библиотека, наречена Zend\ServiceManager, която всъщност представлява мощна имплентация на Service Locator. Тя разполага със собствена конфигурация, която от своя страна говори със Zend\Di.

Новата модулна система

ДА! Това е нещо, от което наистина имахме нужда! Но какво точно ни дава тази нова модулна система?

Преносимост

Преносимостта е нещо, към което всеки програмист се стреми. Целта на новата модулна система е да концентрира разпределянето на логиката в модули, така че да се улесни пренасянето и адаптирането на тази логика в други приложения.

За разлика от Zend Framework 1, не е задължително модулите в ZF 2 да са MVC. Може да напишете модул, който предоставя библиотека, осигуряваща логика за други модули. Например може да имаме модул PayPal, в който да се съдържат класове за разплащане с PayPal, но не и съответни контролери, view скриптове и модели.

Като най-ярък практически пример за мощността на новата модулна система е създадената общност за разпространение на модули – http://modules.zendframework.com. На тази страница всеки може да публикува модули и всеки може да използва такива. Това ще направи разработването на проекти със ZF 2 още по-бързо и лесно.

Лесна конфигурация

В Zend Framework 1 бяхме свикнали да пишем платформената конфигурация в .ini файлове. Това осигуряваше добра четимост, но в някои случеи беше трън в очите за хората, които търсеха висока производителност. Освен това липсваше зареждане на модулна конфигурация по подразбиране.

В ZF 2 за конфигурация по подразбиране се използва асоциативен масив.

Освен глобална конфигурация, всеки модул може да предостави своя собствена конфигурация. При стартиране на системата, настройките на всички налични модули се смесват заедно с глобалната конфигурация, и се зареждат в модул-мениджърът.

Заключение

Няма да ми стигнат 100 страници да опиша (дори на кратко) всички нововъведения в ZF 2, но наблегнах на най-важните и забележителни възможности на новата платформа. Разбира се, въпреки положителните отзиви около ZF 2 аз не смятам, че той е перфектен. Все още е рано и не съм се натъкнал на неприятни характеристики, но съм сигурен, че съществуват.

С голямо удоволствие ще наблюдавам израстването и развитието на фреймуърка, но съветвам ZF разработчиците да не прибързат със Zend Framework 2.

Zend Framework не е най-добрият фреймуърк, той просто е в класация „Топ 1“.

Днес трябваше да оптимизирам един мой проект на Zend Framework. На домашния си компютър не бях работил с профайлъра на Zend Studio, така че се заех да го конфигурирам.

Мина известно време в неуспешни тестове, като ми се връщаше една и съща грешка – „A timeout occurred when the debug server attempted to connect to the following client hosts/IPs: -127.0.0.1

Взех да се ровя в интернет, но в крайна сметка реших да подходя по-класически и да оставя Zend Studio – активирах си xdebug и му включих профилинга. Но когато отворих генерирания профил с KCacheGrind бях изненадан, че execution flow-а на приложението ми мистериозно прекъсва до една доста начална позиция.

Изниза се около час претърсване в гугъл за този проблем, но след очаквания неуспех се заех да прегледам отблизо PHP конфигурацията си.

 

В крайна сметка се оказа, че преди време съм си инсталирал XCache (доста добро opcode cache разширение за PHP), което влиза в конфликт с дебъгерите (което е доста логично). Общо взето който и да е opcode cacher би попречил на дебъгването. Веднага следкато изключих XCache всичко беше наред.

Ще разгледаме конфигурирането на Zend Framework върху Linux и Windows.

Конфигурацията на Zend Framework в общи линии е добавяне на пътят до библиотеката на Zend Framework в PHP директивата include_path и конфигуриране на ZF Command Line Tool.

1. Линукс

Като широко разпространена дистрибуция, примерите са направени на Ubuntu (10.10), но би трябвало да работят подобно и на всички други дистрибуции.

Първата стъпка е да се сдобиете със Zend Framework. Това може да стане по няколко начина – да го инсталирате като пакет от терминала, да го изтеглите от официалния сайт на ZF – http://framework.zend.com/download/latest* или да използвате SVN хранилището на фреймуърка.

* На страницата Downloads -> Latest Release ще се покажат няколко възможности за сваляне на фреймуърка. Първата (Zend Framework + Zend Server Community Edition(CE)) е само ако искате да свалите ZF в комплект със Zend Server. Zend Server e пакет съдържащ конфигурирани Apache, PHP, MySQL, Zend Framework, phpMyAdmin, etc. Zend Server е най-удобен ако сте Windows потребител.

Инсталиране като пакет

Този метод на инсталиране е за предпочитане!

Най-лесният начин да се сдобиете със Zend Framework под Ubuntu е да го инсталирате като пакет.

Отворете терминал и въведете

$ sudo apt-get install zend-framework

Тази команда ще инсталира за Вас последната стабилна версия на ZF. Инсталацията ще свали файловете в /usr/share/php/libzend-framework-php

SVN Export

SVN (Subversion) е широко използвана система за контрол на файловите версии(повече за SVN може да прочетете тук).

В бъдеще ще напиша статия специялно за SVN и Version Control системите. Ако не сте наясно, по-добре изтеглете Zend Framework по стандартния начин.

За да инсталирате SVN на Ubuntu въведете следното в терминала:

$ sudo apt-get install subversion

След като SVN се инсталира, създайте папка, в която искате да изтеглите ZF:

$ mkdir zend-framework

$ cd zend-framework

Не забравяйте втората команда! Ако не смените директорията, ZF ще се „стовари“ в home/потребител папката ви, а това е нещо, което не бихме искали да се случва.

За да изтеглите файловете, трябва само да напишете следната команда:

$ svn export http://framework.zend.com/svn/framework/standard/trunk/ ./

Изтегляне от сайта

http://framework.zend.com/download/latest

Изтеглете Zend Framework Minimal Package и разархивирайте в папка по избор. За да изтеглите и разархивирате от терминал, може да използвате следните команди:

$ wget http://framework.zend.com/releases/ZendFramework-1.11.2/ZendFramework-1.11.2-minimal.tar.gz ./zend-framework.tar.gz

$ tar xvzf zend-framework.tar.gz

Zend Framework е изтеглен в /home/потребител/zend-framework

Конфигурация

Следкато вече имаме Zend Framework, трябва да направим малко настройки.

Отворете php.ini и намерете следните редове:

;;;;;;;;;;;;;;;;;;;;;;;;;
; Paths and Directories ;
;;;;;;;;;;;;;;;;;;;;;;;;;

; UNIX: „/path1:/path2“
include_path = „.:/usr/share/php“

Тук трябва да направите промяна на include_path, трябва да добавите пътят до папка наречена library, която сте свалили (/home/потребител/zend-framework/library). При добавянето на директория в include_path не бива да забравяте да добавите „:“ преди новата директория. Ето пример за това как може да изглежда един include_path:

include_path = „.:/usr/share/php:/home/потребител/zend-framework/library“

Запазете файла и рестартирайте уеб сървъра си. Ако използвате Apache – sudo service apache2 restart или sudo service lighttpd restart за Lighttpd

Остава само да добавим и един  скрипт в /usr/bin по-известен като CLI Tool. В следващата глава ще обясня за какво служи този скрипт.

В директорията /home/потребител/zend-framework трябва да съществува папка на име bin. Въведете тази команда от терминала:

$ sudo ln -s /home/потребител/zend-framework/bin/zf.sh /usr/bin/zf

2. Windows

Най-лесният начин да инсталирате Zend Framework под Windows е със Zend Server CE.

Zend Server е пакет съдържащ в себе си PHP, Apache, MySQL(по избор), Zend Framework(по избор), phpMyAdmin(по избор).

Няма нужда от никакви настройки.

Ръчна инсталация

Ако все пак вече имате инсталиран сървър, и той не е Zend Server, ето как да инсталирате ZF ръчно:

  1. Изтеглете Zend Framework от тук(изтеглете предпоследния пакет – Zend Framework 1.**.** Minimal)
  2. Разархивирайте в папка по избор
  3. Отворете php.ini и намерете следните редове:
    ; Windows: „\path1;\path2“
    ;include_path = „.;c:\php\includes“
  4. Добавете пътят до папката library в include_path (не забравяйте да махнете ; пред ;include_path). Трябва да се получи нещо такова: include_path = „.;c:\php\includes;c:\път\до\zend\framework\library“
  5. Рестартирайте Apache

Какво е Zend Framework?

Zend Framework е Open Source, MVC базиран и обектно-ориентиран фреймуърк за PHP 5 приложения създаден от Zend Technologies през 2005 година. Zend Framework e use-at-will система, което означава, че всеки един компонент използва почти или никаква свързаност с другите компоненти. Това помага на разработчици, които не искат да използват целия феймуърк, а само отделни компоненти.

Дали Zend Framework е за мен?

Ако сте PHP разработчик и имате нужда от добра рамка, в която да творите, Zend Framework e точно като за Вас.

Ако сте начинаещ PHP разработчик, който иска да развие мисълта си обектно, Zend Framework е задължителен за Вас.

Ако сте Java разработчик, Zend Framework ще е лесен и приятен за Вас.

По какъв начин може да ми помогне Zend Framework?

Zend Framework е web application framework. Най-честото му приложение е за създаване на комплексни уеб системи, но все пак библиотеката му може да се използва разделено, така че може да се чувствате свободен да използвате който искате компонент в каквато искате система.

Критика към теб, разработчико!

Ако Вие сте PHP разработчик, който си мисли, че разликата между PHP 4 и 5 е само в цифричката и  „някаква си там оптимизация“, то Вие сте нищо повече от един ЛЕЙМЪР!

PHP е най-широко използваната платформа за уеб системи в Интернет. Това обаче е нож с две остриета. Ето плюсовете и минусите на PHP:

Плюсове

  • Лесен за научаване
  • Безплатен
  • Бърз
  • Безброй много учебни статии и уроци в Интернет

Минуси

  • PHP не е строго типизиран език. За програмисти на C++/Java в началото PHP ще им бъде неудобен.
  • Има много начини за реализация на един проблем. Това създава лоши навици, особенно когато говорим за PHP 4 и PHP 5.
  • Безброй много учебни статии и уроци в Интернет – това както плюс, така е и голям минус. Повечето уроци, които ще намерите в Интерет са за PHP 4, а писането в стила на PHP 4 е паразитизъм(защо? Виж по-долу).

PHP 4 vs PHP 5

Когато PHP 4 е бил пуснат, създателите му не са имали предвид колко комплексни системи могат да бъдат разработени на него. В PHP 4 липсват цял тон възможности, които са пречка в проектирането на сложни системи. Но няма страшно! PHP 5 e тук от 2004-та година, като в него се взимат под внимание най-големите слабости в писането на код от високо ниво. Именно всеки един компонент на Zend Framework е написан на PHP 5, спазвайки стандарти за писане на код, взаимствани от Java.

„Проектът ми работи на PHP 4 и на PHP 5!“

Всъщност проектите, които работят на PHP 4 и 5 са чист PHP 4 код, с изчистени грешки за предпроцесора PHP 5. Пета версия може спокойно да процедира PHP 4 код(представете си колко хора щяха да се откажат от PHP ако скриптовете им не работят правилно с пета версия), и ако проекта Ви работи и на двете версии, значи е на чист PHP 4 (искам да Ви кажа, че няма за кякво да се радвате). Проекти, за които пише, че робатят както на PHP 4, така и на 5, не се възползват от силата и възможностите на пета версия на PHP, която смело мога да кажа, покрива повечето от изискванията за един съвременен обектно-ориентиран език за програмиране.

Предимства и недостатъци на Zend Framework

Предимства

  • Богата библиотека
  • Изчерпателно документиран и разбираем сорс код, спазващ скриктен стандарт за качество
  • Гъвкава софтуерна архитектура. Не ограничава разработчиците
  • Последни възможности на PHP 5. Фреймуъркът с най-изчерпателно използване на PHP 5
  • Подробна документация на няколко езика + удобен и разбираем 30 минутен Quick Start урок.

Недостатъци

  • Zend Framework е „дебел“. Ако искате системата Ви да върви бързо, трябва да отделите специално внимание на бързодействието и оптимизацията на кода си.
  • Zend Framework е труден. Ако досега не сте се сблъсквали с фреймуъркове или още по-лошо, не сте чели чужд сорс код, може да ви бъде много, много трудно…
  • Тъй като именуването на класовете в Zend Framework спазва PEAR стандарта, те могат да бъдат доста дълги, което може да ви нервира от време на време(версия 5.3 на PHP се „запозна“ с пространствата от имена, което ще реши проблема с дългите имена. Очакваме използването на namespaces в Zend Framework 2.0, който ще дойде съвсем скоро!)
  • Липсата на уроци в официалната документация на сайта

Zend Framework алтернативи

Simfony – ще цитирам един мой познат: „Simfony е прекалено добър!“

SolarPHP – има доста прилики със Zend Framework

CakePHPНе ми харесва (pure hate)

CodeIgniterне го препоръчвам на никой. Пълна бъркотия!

Има още много, като Yii и eZ Components, но тях не съм ползвал и не мога да дам компетентно мнение.