Framework’lere başlarken
Framework’lere girişim
Framework’leri uzun zamandır çok yakından incelesem de, hiçbirisi içime sinmedi. Çoğunlukla da geleneksel çözüm üretme yerine çok katı yapısal kuralları olan araçları öğrenmeye yeterince zamanım olmadığı görüşünde olduğumdan böyle hissettim. Bu belki de şimdiye kadar web uygulamaları konusundaki yeni araç / teknoloji / yöntem ‘i uygularken karşılaştığım en acılı`learning curve` safhasını öngördüğümden böyle oldu. Fakat makaleleri okudukça, gerçekten ne kadar hızlı uygulama geliştirildiğine, ne çok ‘tekerlek icat’ ettiğime tanık oldum. Dolayısıyla öğrenme zamanı masrafını riske edip, bir anlamda kırmızı hapı içip, frameworkler hakkında kendi tecrübelerimi oluşturmaya karar verdim.
İlk soru, tabii ki hangi framework sorusu oldu. Hepsi hakkında gördüğüm birbirlerinden farklılık yaratan özet bilgiler, şu şekildeydi;
- Code Igniter: Hızlı, esnek, kolay, öğrenme süreci hızlı
- Zend FrameWork: Uzman, enterprise uygulamaları kaldırabilecek – acılı öğrenim süreci, kimine göre en hızlısı, kimine göre en yavaşı, ne yaptığını bilen insanlar tarafından geliştirilmiş
- Symfony: Uzman, enterprise uygulamaları kaldırabilecek, en çok özelliği barındıran
- cakePHP: En iyi MVC, en iyi Framework, en iyi Ruby on Rails PHP Kapısı, en çok automation (sihirli) fonksiyonu bulunduran, en kolay
Bunlar söylenirken, keşke mantıklı, açıklayıcı makaleler bulabilsem, fakat çoğu takım tutar gibi framework savunuyor. incelediklerimden sadece IBM objektif bakmış ve her framework’de (Code Igniter hariç) bootstrap, veritabanı bağlantısı, vb temel öğeleri kullandırarak birer uygulama örneği yapmış. Makaleye buradan ulaşabilirsiniz.
Symfony – PHP’ye konser verdirmek
Genelde kararsız ve katı bir fikre sahip olmadığım zamanlarda ve konularda büyük araştırma bütçelerine sahip, teknoloji araştırırken iliğine kadar araştırıp geçiş kararı alan , User Interface konsunda büyük özen sahipi internet hizmeti dünyasının başlıca şirketlerinin kararlarını hep kayde alarak/esinlenerek kendime yön vermişimdir. Yahoo’nun PHP’ye geçişi, dünyanın en büyük ilişkisel veritabanı sahibi olduğu söylenen friendster’in ve facebook’un MySQL tercih etmeleri gibi, framework seçiminde de yakın zamanda Yahoo’nun Symfony seçimine yöneldim. Bu yüzden her ne kadar IBM’in makalesinden (gördüğüm tek elle tutulur makale) cakePHP sonucu çıksa da ilk seçimim Symfony oldu.
Öncelikle ne kadar iyi belgelendigi (documentation) , API Referance’a sahip olduguna baktım. ORM’siz var olamayan Symfony beni kısa sürede kullanmayı pek sevmediğim şema dosyalarına bulaştırdı. Hakkında pek çok şikayeti bulunan Propel kullanıyordu. Bir süre YAML formatlı bu sıkıcı şema dosyalarıyla uğraştıktan ve sonunda bootstrape benzeyen birşey çıkardıktan sonra, propel’in ne kadar yavaş olduğunu tecrübe ettim.
Sonuç olarak bu kısa deneyimde hızlıca symfony’nin hem uygulama geliştirme hızı açısından hem de kod performansı açısından, spaghetti koddan benim gözümde daha düzgün görünür olmadığına inandım. Üzerine bir de propel’in yavaşlığı gelince, iyice bozdu hevesimi. Akabinde propel’e alternatif Symfony’nin doctrine ile çalışmaslarını gördüm. (doctrine, propelden sonra baya övgü alıyor). Fakat doctrine ancak Symfony 1.1 Beta ile çalışıyor. Kısacası ‘Ohooo daha beta’ mazareti/bahanesiyle beni zart zurt şema kullanmaya zorlayacak bir framework’ü istemedim, ve caydım.
cakePHP ile baklava açalım, muhabbet edelim
Makale sonucundan cakePHP’yi ilk deneme tahtam olarak seçerek, IBM’inkinden daha kapsamlı ve proje ihtiyaçlarına göre ayarlanmış database wrapperını, view’unu, MVC yapısını uygulamaya başladım. Modeline az çok ORM’yi de katmış bir model yapısıyla karşılaştım, beni oldukça sevindirdi. hasMany, belongsTo, vb tanımlar foreign key’ini kodda tanımlayabileceğin ve veritabanı yapısını iş akışıyla birlikte tanımlandığı, Framework’un bu yapıyı esnek bir biçimde kodun farklı yerlerinde (MVC gereği controllerda) manipüle etmeye izin veren bir yapısı vardı, oldukça kanım ısındı. View’unu, layoutuyla, elementleriyle zaten şiir gibi oluşturdum. Controller’dan zaten çok birşey beklemiyordum, beklentilerimin tamamını karşıladı.
Sihirli fonksiyonlarının SQL bilgisini, HTML hatta JavaScript bilgisini bile (automated ajax kullanmakta) neredeyse gereksiz kılması beni, bu framework’un ‘cakePHP bilin, herşeyi bilin’ tarzında bir görüşü sahiplendiği fikrini oluşturdu. Bu fikir git gide yüzümü ekşitmeme neden oldu; ne zaman manual’ı açsam, bana güzel örneklerle mantıklı cevaplar vereceğene bütün sevimliliğini takınıp ‘canım bitanem bunu cakePHP yolundan yap, bak ne güzel sihirli sihirli geçinelim’ diye bitakım direktifler veriyordu. Bu duruma bozulsam da en azından sonuç alabildiğim için devam ettim. Çalışmama devam ederken router’ının ve MVC yapısının sihir fonksiyonlarıyla olmayacağına ve tanımlamaların yetersizliğini gördüm. Elimdeki sorunun çözümlerinin cakePHP core class’larının extend etmemle başarabileceğim görüşünü aldım, extend ettim, artık commentlerde manualdeki gibi pek de sevimli olmayan ‘Bunu böyle yap! Aman buna dokunma dağılır!’ gibi bir havayla karşılaştım, o vakit ayrılık kararımı verdim.
Son fikrim, cakePHP’de hızla kişisel bir blog yapılır, hızla bir forum yapılır, ama asla CRM, karışık hiyerarşi / iş tanımı barındıran uygulamalar sıkıntı yaşamadan, binbir takla atmadan yapılamaz. Daha sonra merakımdan, acaba cakePHP mi birşeyler atlamış yoksa orjini Rails de mi böyle diye araştırdım; evet, cakePHP iyisiyle kötüsüyle babasına çekmiş bir framework. Ayrıca binbir helper da kullanmak istemiyorum. Ayrıca PHP’nin JavaScript’ten ayrılmadığı bir framework view’u controller’dan ve model’den ne kadar uzak tutabildiğini iyi ki görmedim.
Code Igniter – Sexy kodlar
İki framework’ün yorucu yapısından bezmiş olarak araştırmaya devam ettim. Özellikle Manual’ının çok övüldüğü, öğrenmesi hızlı, cakePHP’nin sihirbazlığından gına gelmiş ve Zend Framework / Symfony ağırlığında olmayan geliştiricilere hitap eden Code Igniter’ın ilgimi çekmesi zor olmadı. Öncelikle gerçekten cakePHP ve Symfony tecrübesinden sonra çok rahatladım, onlarda yarattığım örnek uygulama çok hızlıca çıktı. cakePHP’nin hasMany, belongsTo tanimlamalari, findKullanici vb sihirbazlari yoktu ama zaten SQL bilme zorunluluğu olan web geliştiricilerinin olmazsa olmazları içinde de yoktu. Kısacası herşey çok kolay, hızlı çıktı. Fakat genel framework özellikleri biraz yetersiz gelmeye başladı. Örneğin, keşke cakePHP’nin view’u bunda olsaydı dedim. Biraz araştırma yaptım, ortalıkta 1-2 layout ve element denemesi olsa da cakePHP kolaylığında ve hiyerarşisinde çalışmıyordu fakat farketmediğim bir özelliği de bu makaleler sayesinde keşfettim, CI ‘da işleyişin tamamını kolayca, core’a dokunmadan değiştirmen için hook kolaylığını getirmişler. -Edit: Code Igniter’a eklediğim Layout özelliğine buradan erişebilirsiniz- 3 saatte CI’ya cakePHP’nin bütün layout ve html element (renderElement) view’unu implement etmiş buldum kendimi. Gelgelelim, işimiz biraz karmaşıklaşıp, klasik frameworkünkilere uymayacak routerlar yazmaya gelince gene CI yetersiz kaldı.
Herşey çok basitti fakat yapılacak iş biraz karmaşıklaşınca, tamamı yetersiz kalıyordu. Örneğin route belirlemek çok kolay, ama karmaşık route tanımları yazmaya gelince çok geçmeden, işin çözümünün bir MY_Router yazmaktan geçtiği belli oldu. Forumlarda, tecrübeli kullanıcılar ise uğraşmayın canım, yazın mod_rewrite ile demekten başka pek yardımları olamadı, sonuçta öbür seçeneğin özel kod olduğu belli. Eh, routing’i PHP’nin bilmesi gerekmiyorsa, zaten bunu PHP ile yapıp performans düşürmenin alemi yokki diyip, bu durumları handle etmesi icin gene router’ı extend ettim. Hiyerarşi oluştururken ACL (Access Control List) kütüphanesini kullanmam gerekti, fakat ACL’i iyi düşünülmemiş, ARO (Access Request Object) ‘larda gruplama / hiyerarşi sözkonusu değildi ve sadece CRUD (create read update delete) destekliydi. Tamam dedim, gittim kendi ACL’imi yazdım, herhangi bir kodda ACL ne kadar hızlı yazılırsa, o şekilde bir library yazdım. Ama buarada en azından benim projem için CI_Acl de çöpe gitti.
Sıra sitede multilang oluşturmaya geldi. Dil secimini sessiona veya cookieye atmayıp Google dostu /en/firmalar/.. seklinde URL’ler yaratmaya geldi, tekrar routinge dalarken artık yüzüm gülmüyordu. Code Igniter’daki model classlarında $_POST ‘u gormemle (gözümden kaçmış), yok daha neler, artık manualde de böyle bir hata olmaz ki şeklinde mızmızlanmaya başladım. Düşünülmüşlük ve MVC yapısının sağlamlığı konusunda Symfony beş basardı.. Kendimi tekrar şemaların işkencesine, propele dönüş yapacağım düşüncesine alıştırmaya başladım. Derken, Zend Framework 1.5 betadan çıktığını duyurdu.
ZF’ye geçmeden, Code Igniter konusundaki son fikrim şu; eğer en azından MVC ‘ye az çok benzeyen, az çok kodun, bootstrap’i hazır bir framework arıyorsanız, budur. Esnekliği kullanıcının emeğine bağlı ama işleri usandırmadan yaptıran bir yapıya sahip olan Code Igniter kesinlikle küçük projelerde 1 numaralı seçimim olur.
Zend FrameWork – Usta’nın alet çantası
Symfony’yle yaşadığım eziyetten sonra, Symfony ile ismi birlikte anılan Zend Framework’ün içine girme fikri aslında başta çok uzaktı. IBM örneklerindeki uzun tanımlamalar, bootstrap’inin kalın olması, vb hep uzak geldi. Kafamda başlarken daha nasıl olsa Symfony’ye dönüş yapacağım düşüncesi vardı. Her işe başlarkenki gibi ilk başta dökümantasyonuna baktım. Bir devasa Developer’s Guide, bir de PHPDoc API buldum. Documentation cakePHP, Code Igniter diğerlerinin aksine ‘haydi hem eğlenelim, hem öğrenelim bak o kadar da zor değil’ yerine ‘Elinizdeki şu işe yarar, mantığı budur’ şeklinde ciddi ve tatmin edici bilgiler vardı. Yani soruları sizin sormanız gereken, dolayısıyla doğru soruları sormanız gereken bir dokümantasyon bu. Ortada diğerlerinin aksine bir başlangıç dersi yoktu nitekim FrameWork’ün bütün modülleri, teker teker açıklanmış durumdaydı. Birileri, elbette “herkesin her terimi ve yöntemi bilmesi beklenemez, neyin nerede olması gerektiğini herkes kestirmek zorunda değil; mutlaka yönlendirme olmalı” diyebilir; fakat bunun adı geliştirici dokümanı, diğerlerininki gibi ‘el kitabı’ değil. Özetle bana göre o ana kadar okuduğum dökümantasyonlardan en yüksek puanı alarak geçti.
Sıra ZF’ui projemde kullanarak uygulamaya geldi. Yapı modüler olduğu ve hiçbirşey öntanımlı/kısıtlayıcı olmadığı için ortada hazır bir bootstrap de yoktu. İlk iş, bir bootstrap dosyası yaratarak (genelde index.php de başlar, ve config/load phpleriyle devam eder), ZF’nin nelerini, hangi sırayla, hangi MVC yapısıyla, hangi routerla, hangi dizin yapısıyla kullanacağını belirlemekten ibaret oldu. Açıkçası en azından MVC’yi önden tanımladığını düşünüyordum fakat onu bile yapmadı. Bootstrapinizde front controller tanımlamadığınız sürece, MVC kullanmak durumunda bırakmıyordu, hatta bir parametreyle aynı bootstrapde hem MVC, hem spaghetti kullanabileceğim sözkonusuydu. Bootstrap’i oluşturmaya başladım, bu yaklaşık 1 haftamı aldı diyebilirim. Sırasıyla Front Controller’ı (MVC), Route’u (url rewrite), Locale’i (çoklu dil ve dillere özgü destek) , Autoload’u, Registry’si, Cache’i (ayrıca ZF’den değinmek için ) derken bootstrap bitti. Bootstrap oluştururken ZF ‘ye bağımlı kaldım fakat bitane extend’im, bu modül bana cevap vermeyecek dediğim birşey olmadı. Modüller gördüğüm en iyi düşünülmüş işlevlere sahipti. Olması gereken herşeyin frontend, backend’i vardı. Yani çağırılış işlevleri ayrı classlar, arkaplan çalışması ayrı classlar tarafından yürütülüyordu. Router’ı mod_rewrite’ın yapabildiği herşeyi destekliyor, bide üstüne bu da var diyordu. Örneğin Zend_Cache’i huzurunuza çağırdığınızda “sayfaları mı cache’liyeceksiniz, yoksa büyük array, fonksyion, object lerimi?” diye sormakla kalmıyor, ekliyordu “backend olarak dosyada mı saklamak istersiniz, yoksa veritabanında mı tutayım? İsterseniz memcache kullanarak memmory’de dursun jet hızıyla erişin.”
Kısacası ZF ile neyi nasıl yapacağım kafamda oturdu. Sunduğu araçların hepsi, her türlü kullanıma, her yola geliyor. Buna karşın geliştirme aşamasının en uzun ‘Learning Curve’ olarak anılan, öğrenme sürecine sahip, fakat umduğumun aksine sıkmadı, hatta core kodlarını incelerken programlama tekniklerinde de bana çok şey kattı. Önümde duran koskoca projede işlerimi nasıl hızlandıracağından, hemen her projemde sıkıntı çektiğim nereden başlayacağım sorusunu da bootstrap’i oluşturarak emin oldum. Herşeye rağmen ZF’yi sadece büyük projelerde kullanacağımı sanıyorum. Bu framework’ü sık kullanacağım iki framework’den biri olacağından, Code Igniter’ın yanında kategori olarak tanımlamaya karar verdim.
Son olarak
cakePHP’nin sihirbazlığını kimileri çok sevse de, ben ısınamadım. Code Igniter’ın esnekliği tamamen custom kod yazımının kolaylığından ve komplike tekniklerin kullanılmamasından geliyor. Zend Framework ise gerçekten iyi düşünülmüş bir araç. Çağırıldığında biraz yavaş geldiğinden, küçük, hızlıca bitirilmesi gereken projelerde kullanılmasının gereksiz vakit ve işgücü sorunu yaratacağını sanıyorum. ZF yol yordam bilenlerin taşıyabileceği ve ancak büyük işlerde çağırılması gereken bir araç.
Nisan 7th, 2008 @ 11:12 pm
Güzel bir türkçe açıklama olmuş, elinize sağlık, aynı frameworkleri bende incelemiştim, artı olarak biraz da Seagul kurcaladım, Zend in öğrenme zorluğu, Cake in herşeyi ben yaparım siz oturunculuğu derken en son CodeIgniter kullanmaya karar vermiştim onda da kullanılan MVC yapısı biraz ters gelse de alışılabilir diye düşünüyorum, uzun zamanın smarty alışkanlığını bırakmak istemediğimden dolayı, ve Smarty nin bu sayılanlar içinde en kolay Zend ile kullanılabiliyor olması yüzünden birkaç projeyi Zend+Smarty kullanarak oluşturmayı deneyecegim.
Nisan 8th, 2008 @ 10:35 pm
Merhaba Gökçe,
Daha öncede konuştuğumuz gibi. ZF her yöne yönlendirilebiliyor. Bir arkadaşım ZF library’sini kullanarak kendi Framework’ünü yaptığını söylüyordu tabiki yalan :)
Zend bu işin uzmanı, PHP konusunda ne yaptıklarını biliyorlar ve yaptıkları kodlamalar gerçekten öğretici, özellikle framework dökümantasyonu içerisinde “Coding Standarts” kısmı ilgimi çekmiştir.
İnsanlara global standartlarda kod yazma ve ekip kodlaması üzerine gerçekten güzel bir imkan sağlıyor.
ayrıca Zf ‘nin şu şekilde güzel bir yapısı daha var bence. 1.0 ile oturduğu günden beri stabil bir yapıda izliyor. Dolayısı ile sabit bir yapı oluşturup o yapı üzerinden çeşitli bprojeler oluşturulabilir.
Saygılar.
Nisan 9th, 2008 @ 10:52 am
@A.Karakilcik: Smarty konusunda ben de çok düşündüm, fakat Zend veya herhangi bir framework’ün view’u neredeyse standartlaşmış olarak helperlar (smarty’de plugin) layout ve elementler’den oluşuyor. Cache / compile optimizasyonu gerekmiyor, çünkü framework’ün (özellikle Zend’in) bu konuyu Smarty’den daha iyi yaptıkları aşikar, ne de olsa sadece template değil; framework, bütün uygulamanın çekirdeğini oluşturuyor. Tabii ki bu iş takım tutmaya benzemiyor; Smarty’yle daha rahat davranılıyorsa, öyle yapılmalı. Ama -bence- herhangi bir framework’de template engine kullanılması çok doğru değil. MVC’in View’u hem çok gelişkin, hem sadece PHP’yi kullandığından işlevselliği de yükleniyor. Mesela smarty’ye atanan değişkeni printf’le gösteremiyoruz, gidiyoruz bunun için modifier plugin yazıyoruz, vb
Nisan 9th, 2008 @ 10:57 am
@Murat BEŞER: Valla framework yapmak aslında hiç zor değil; Rasmus’un No framework MVC Framework buna örneklerden. Lightweight sadece kendi istediğin şeyleri bulundaracak bir framework hazırlanabilir. ZF Library olarak kullanınca zaten elinde koskoca bir kalıp oluyor, ama arkadaşın yapınca farkı ne olacak, o kalıba uygun davranıp ZF kadar kullanışlı yapabilecek mi o önemli.
Nisan 10th, 2008 @ 4:57 pm
Benim de üzerinde çokça düşündüğüm ve gözümü kestirip başlayamadığım framework’ler için gayet güzel ve yardımcı bir makale olmuş.
Teşekkürler
Nisan 10th, 2008 @ 8:44 pm
[...] Igniter’dan frameworklerle ilgili ilk yazımda kısaca bahsetmiştim. Code Igniter’ın benim için en kötü özelliği, herşeyin birbirine [...]
Nisan 20th, 2008 @ 4:44 pm
Merhaba, Aslında Fw’ler önemlidir. Makalenizde çok güzel olmuş emeğinize sağlık. Allah zihin açıklığınızı devam ettirsin lakin, ben herhangi bir Fw’nin Database kütüphanesini kullanacağıma şu an itibari ile “Php 5.2″ sürümleri ile gelen PDO nesnesini kullanmayı tercih ederim. bunu söylememdeki gerekçe şu olabilir.
Özgürlüğümü kısıtlayacak bir libary benim önümde engeller oluşturabilir. ve benim yaratıcılığımı yok edebilir endişesini duyuyorum. yanılabilirimde ama çok defalarca fw lere geçmeme rağmen bırakmam bir oldu sadece bir dönemler adodb kütüphanesini kullanmıştım ve beğenmiştim. ama kısa bir uğraş sonrasında adodb ye benzer bir database libary. kendimde yazabileceğimi düşünüp kendi libarylerimi yazıp kullanmaya başladım. kanımca ZendFreamwork’a soğuk durmamın sebebi uzun Class Nameleri. :)) onları ezberlemek istemiyorum. bu arada sizin gibi Programcıların olması beni sevindirdi. Sitenizi sık kullanılanlara ekledim.
Çalışmalarınızda başarılar.
Örneğin Da
Nisan 21st, 2008 @ 12:01 pm
Merhaba, öncelikle teşekkürler,
Yorumlarınıza gelince, PDO, herhangi bir frameworkle kullanılabiliyor. Sadece tanımlanması gerekli. CI ‘da DB – CI arası pek esnek kurgulanmamış, illaki core düzenlemesi gerektiriyor, fakat CI Core’u çok komplike olmadığından sanki tanım yaparmış gibi PDO implement edilmesi mümkün. ZF zaten PDO ve daha bir çok layer kullanıyor. ZF ‘deki uzun class isimlerine gelince eğer code analyzer destekli bir Editor/IDE kullanıyorsanız tersi yararlı bir duruma geliyor, ezberlemek zorunda değilsiniz, “zend_rou” yazınca ilgili butün sınıflar da seçilip kullanılmak için huzurunuza geliyor, Class isimleri hiyerarşik (Zend_Router , Zend_Router_Route, Zend_Router_Route_Abstract vb) ve herbirinin ismi ZF Coding Standart meyvesi. Son olarak Adodb ye gelince bir framework değil, o da PDO gibi DBMS Wrapper.
Framework kullanmalı mıyım? Cevabı, sanırım işlerimizi yaparken tekerleği yeniden icat etmemek adına türlü türlü libraryler kullanıp kullanmadığımız. Eğer bu library’ler çoğunluktaysa, neden Router işi dahil birbirini tanıyan, hepsi aynı düzene sahip, iyi düşünülmüş library’lerle çalışmayasınız? Sadece bu da değil, frameworklerde, -özellikle ZF’de- libraryler’in abstractları, interfaceleri ve eğer bir servisse connector’ları ayrı ayrı tanımlandığından çok kolayca değiştirilebiliyor, abstract classlarının yardımıyla kendi özgün librarynizi geliştirebiliyorsunuz. Örneğin, kodun her tarafında PDO kullandığınızı düşünün, ve bir nedenden uygulama ORM ‘ye (örnek doctrine) bir yapıya ihtiyaç duydu. ZF ile bunun tanımı 30 satırda bitiyor o da çeşitli tanımlamalardan ibaret, sonra istediğime geçiş yapabiliyorum ve artık doctrine bütün ZF yapıma da uyum sağlayarak hareket edebiliyor. Peki 5000 PDO spesifik işlem içeren bir spaghetti kodda bunun yapılması ne kadar zaman alır?
Özgürlüğü kısıtlama konusunda ise neredeyse bütün Frameworklerde haklısınız. Hepsinin bir kuralı var. Fakat MVC’ye girince yazılım dizaynı gereği bir takım kuralları olması şart. Ama bu kurallar gene de bazılarında esnek (ZF,CI,Agati), mesela normalde form doğrulama veya DB çağrısı Controller’da olamaz, bu Model’in işidir; fakat bu MVC’nin faydalarını gözardı etmek anlamına gelse de bütün dilerseniz istediğiniz yerden istediğinizi çağırabilirsiniz, hatta uygulamanızın tamamını view’larda dahi yapabilirsiniz. Sonuçta karşınızda framework tarafından parse edilen dosyalar değil, normal PHP dosyaları var.
Nisan 21st, 2008 @ 3:58 pm
Merhaba, Yorumunuzda ve makalenizde belirtiğiniz üzere, Fw’ler büyük ve hiyererşik yapılarda kesinlikle gereklidir. Aslına bakarsanız temel Php fonksiyonları dışında OOP ile çalışıyorsak ve burda biraz başarılıysak. eksikte olsa kendi Fw’lerimizi oluşturuyoruz aslında. Class Nameler ise tanımlama olarak zaten uzun olmaları gerekiyor. burda sanırım kendime bir bahane ürettim :). Evet Haklı olarak bütün gereksinimleri karşılamaya yönelik bir çatı altında topluyorsak. olabilecek en kullanışlı isimlendirmeye gitmek zorunluluğu doğuyor.(Yazım Standartlarına Uyumluluk) çünkü İşlem yapan libary ve sınıf sayısı yapılan işlemlerin niteliği ile adlandırılmak zorunda bu konuda bahsettiğiniz gibi Zend Studio veya Eclipse gibi bir IDE kullanıyorsak. Class’larımıza ve Classın Fonksiyonlarına erişmek çok kolaylaştırılmış durumda. Aslında sanki birazda Zend Takımı bu Fw’yi Zend Studio’yu birazdaha güçlendirmek. için el atmış gibime geliyor. İyi ki el atmışlar diyelim.
Açık Söyliyeyim. hala hiç bir çalışmamda bu Fw yi kullanmadım. gerçi siz makalenizde diğer Freamwork’lar dan bahsetmişsiniz.
tabiki tüm dikkatleri üstüne Zf çekiyor. Performans konusunda bir deneyiminiz oldumu. Özellikle Database uygulamalarında?
Nisan 24th, 2008 @ 8:23 pm
Evet, ufak benchmark’larım oldu. Symfony sonda (propel ile) , cakePHP arkasından, ZF ikinci, CI birinci geldi. Fakat durum symphony’nin doctrine’i kullanmasıyla, ZF’nin raw mysql kullanmasıyla, cakePHP’nin mm.. eğer sihirbazlığı cpu’ya nazı geçirirse ki sanmam oturup ağlamasıyla değişebilir. Ortalıkta komik ‘Hello World’, SELECT hede FROM hodo benchmarkları var, bu benchmarklara yapılan yorumlardan en çok hak verdiğim ve güldüğüm, kesinlikle Hello World yazan bir projeyi ZF ile yapmayacağım” olmuştu. İyi bir benchmark ancak aynı büyük uygulamanın bütün frameworklerde gerçekleştirilmesiyle olabilir gibi. Böyle birşeyin olmayacağı neredeyse kesin olduğuna göre, her projenin kullanacağı framework component/modüllerine özel testler uygulamak lazım.
Haziran 1st, 2008 @ 5:09 pm
Gerçekten çok güzel bir yazı olmuş… Faydalandım…
Teşekkür ederim.
Ağustos 22nd, 2008 @ 7:00 pm
güzel bir yazı olmuş. çok faydalandım. ancak programlama dünyasındaki şu ” onumu kullanmalıyım, bunumu, yoksa öbürünümü ” konusu benim en büyük problemim. bazo çok stratejik konularda günlerce hatta haftalarca bunu araştırıyorum, deniyorum, inceliyorum ama yine de bir türlü karar veremiyorum. bu php frameworkler konusu da bu konulardan birisi. aslına bakarsanız sizin de dedğiniz gibi proje ebatlarına göre ZF veya CI en doğru seçim ancak burada da kafamı kurcalayan nokta şu; ben aslında tam olarak programcı demiyorum kendime, programlama ve ilgili şeyler benim için sadece amaca giden bir araç. dolayısı ile araç sayısını ne kadar az tutarsam sonradan destek vs gibi konularda çok fazla zamanımı almayacak en azından hızlıca çözebileceğim bir yapı kurmam gerekiyor. yani ya bütün uygulamalarım CI olmalı ya da büün uygulamalarım ZF de olacak. bazıları CI bazıları ZF olursa destek konusunda biraz daha fazla karmaşıklaşacak gibi geliyor bana.
ZF kütüphanesi zengin ama çok hantal, yavaş, uygulama geliştirmek CI ye göre biraz daha uzun sürüyor ama sağladı esneklik ve araçlar nedeni ile neredeyse başka hiçbir harici çözüme ihtiyaç kalmıyor.
CI ise hızlı, kodlama çok pratik, ama kütüphanesi sınırlı. Özellikle ACL konusunda takıntılıyım ben. CI core framework de bir ACL olsa hiç düşünmeyeceğim. Freakauth vs var ama core a dahil olmadığı için güncelleme ve uyum sorunları nedeni ile sıcak bakamıyorum. CI istek forumlarında bu konuyu açtım ısrarla neden gerekli olduğunu anlattım ama kendileri sadeliğe o kadar at gözlüğü ile takılmışlar ki ikna etmek mümkün değil. kısa vade de olmayacak gibi..
yani kısacası kafamdaki karışıklığı halen giderebilmiş değilim.
şu sıralarda aynı kargaşayı php mi jsp mi konusunda yaşıyorum.
yazınız için tekrar teşekkür ederim.
saygılar
Ağustos 22nd, 2008 @ 10:19 pm
Evet, aynen öyle. Ekleyebileceğim ve önerebileceğim şeyler, öncelikle frameworkler arasındaki hiçbir performans karşılaştırması doğru yanıtı verebilecek nitelikte değil. İş böyle olunca baz alınabilecek tek benchmark echo ‘Hello World’; karşılaştırması oluyor, bu durumda callstack’i küçük olan kazanıyor.. Fakat bu pek adil değil, ve kimse Hello World yazmak için framework kullanmaz. Zira iş büyük olursa, builtin object cache, vb gibi opsiyonlarla ZF, CI’ın performansını bi hayli geride bırakabilir. Esneklik konusunda zaten yazımda da belirttim, bence ZF daha esnek, çünkü abstract sınıfları, methodları, herşeyi genişletilebilirlik üzerine, CI’ya esnekliğini veren şey o ‘ben böyle çalışırım’ diye coreunun çok kolay yeniden düzenlenebilmesi.
Code Igniter’da ACL olayına gelince, evet ACL’i çok eksikti. Bu yanlış kurgulanmış ACL, sanırım rezil olmamak adına sonraki niye geliştirilmemiş de çıkarılmış bilmiyorum. Ben bunun için bir ACL sınıfı yazmıştım, aslında bir uygulamayı, aynı şekilde üç ayrı frameworkde de geliştirdim ve o örnek uygulamaların tamamını paylaşmayı çok isterdim bu yazımda fakat benim “rm -rf cyx *” komutuma kurban oldu. ( rm -rf ‘de cyx* yazacağım yere, * yazınca, bütün tryout projesi uçtu. ) Çok uğraştım geri getirmeye fakat journali olmayan ext3 kullandığımdan, mümkün olmadı.. Neyse konuyu dağıttım.
Önerim elbetteki CI kullanman. Fakat gelişimlerini kendin yapman gerekecek, ileride genel amaçla kullanılabilecek bir ACL yazarsam haberdar ederim, fakat büyük ihtimalle ZF ‘yi kütüphane olarak kullanmak mümkün olduğundan yazmayacağım.
Ve sadelik onlar için elbetteki önemli, çünkü CI’ın gene aynı firmaya ait Expression Engine’in ön ürünü olduğunu unutmamak gerek.
Ağustos 22nd, 2008 @ 10:40 pm
peki ZF ACL sınıfını CI içinden kulanmak için bütün ZF kütüphanesini almak mı gerekiyor yoksa sadece ilgili sınıfı alarak mı bu entegrasyonu yapıyorsunuz?
Ağustos 22nd, 2008 @ 11:14 pm
ZF sınıfları, abstract’leri olsun, interfaceleri olsun çok detaylı. Sadece tek bir sınıfını almak, işinizi oldukça zorlaştıracaktır. Buna rağmen, hepsini almanız bir performans sorunu oluşturmaz, nitekim sadece ilgili sınıfı yükleyeceksiniz, Zend Loader haricinde başka bir sınfıın callstack’i olmayacak. Dilerseniz boyutu azaltmak için xdebug gibi bir profiler ile gerekli olan sınıfları belirleyip, gerisine güle glüe diyebilirsiniz.
Gene de Zend_Register haricinde -CI’in bir yapısal sorunu $CI core sınıfı, singleton olarak zaten uygulamanın başından sonuna kadar çalıştığından, bir registery gerekmiyor- Zend_Cache, Zend_Locale, Zend_Xmprpc, Zend_Translator gibi sınıfları, çok işinize yarayabilir.
Ağustos 22nd, 2008 @ 11:57 pm
peki gökçe bey, kusura bakmayın ısrarla aynı şeyi soruyor olacağım ama… ACL sınıfı sorun değil aslında ben kendi ihtiyaçlarıma uygun olan, tam anlamıyla ACL olmayan, sadece kullanıcı grubu bazlı yetkilendirme yapacağım birşey üzerinde düşünmeye başladım bile CI için… ACL olmayışı sadece, CI in doğru bir seçim olup olmadığını düşünürken kafa bulandıran bir konu. Çok da önemli değil.
Bu iki framework ü derinlemesine incelemediğim ve inceleme şansım olmadığı için bir şey daha sormak istiyorum. gerçi yazmışsınız büyük projelerde ZF kullanılmalı diye… Bunu biraz daha somutlaştıracak olursak. Büyük projeden sizin anladığınız tam olarak nedir. Yani ERP yazılımı tabi büyük bir proje ama.. biraz daha çemberi daraltırsak cms projesi, kobilere yönelik kurumsal özel uygulamalar, shopping card uygulaması gibi uygulamalar için sizce hangi framework seçilmeli. Somut olarak ne tip ve büyüklükte projelerde ZF kullanılmaya geçilmeli. Ben %90 oranında KOBİ lere yönelik uygulamalar üzerinde çalışıyorum. Öyle dev kurumsal firmalara ait projelerde bulunmadım gelecekte de bulunmayacağım. Programlama, yaptığım hizmetin bir kısmı yani sunduğum çözümün bir parçası, tamamı değil.
Bu anlamda bütün işlerimde sadece tek bir framework kullanmak istediğim için daha sonradan CI olmadı, ZF ye dön vs çok problem çıkaracağı için baştan en uygun tercihi yapmak için bu kadar ısrarla aynı soru etrafında dönüp duruyorum kusura bakmayın.
saygılar
Ağustos 23rd, 2008 @ 3:42 am
Öncelikle kesinlikle sormaktan çekinme, nitekim özellikle teknik bloglarda en kısım yorumlardır. Yazı bir giriş yapar, ihtiyacın karşılanmadığı (ki çoğu zaman karşılamaz) bilgi yorumdadır. O yüzden durup duraksamadan aklında ne varsa sorman, blogun da gelecekte benzer sorularla gelecek ve bu yazıyı okuyacak olanların hayrına olacaktır. Bilmiyorsam bilmiyorum der geçerim, burayı paylaşmak için benim, dolayısıyla çilesini de baştan kabul ediyorum yani. Cevap vermediğim an, zaten yazmayı bıraktığım andır ki bu durumun ne sizinle, ne başka bir okuyucu/katılımcıyla alakası olmaz. Tamamen benimle ilgilidir.
Sorunuza gelince, hayır, büyük uygulamaların içine, CMS’i veya çoğu* kurumsal özel uygulamaları, e-ticaret ürün satış sitelerini katmıyorum. CI bu işler için bulunmaz kaftan. Alışıldıktan sonra herşeyde ZF kullanılabilir ama (emlak sitesi için ZF kullanan azimli arkadaşlar tanıyorum, murat merhaba de ;) -ama aslolarak, ORM’yi de katınca işin içine Yahoo, Facebook gibi uygulamalardan bahsediyorum. O kadar büyük olmalarına gerek yok tabii, ama aşağı yukarı büyük ve tek, sürekli release değil, sürekli bakım ve yenileme gerektiren projeler için. Ayrıca CI’da bir CMS, Blog yada Web Muhasebe, Varlık Modülleri, Araç Bakım, Şantiye Yönetimi vb çıkarma hızı, Zend’i kat kat katlayacaktır.
Örneğin Yahoo, ZF’ye işlev olarak denk Symfony’yi kullandı. Symfony seçimlerinde, orda burada yapılan yazılı dedikodulardan duyduğum şey, bir başka şirketin adının kullanılmaması ve ZF’nin geçiş zamanlarında çok genç olduğu. ZF bir yıl hatta belki daha fazla beta kaldı, ama bunun gene sebep olduğunu düşünmüyorum çünkü Symfony’yi alıp, bir ton üzerinde gelişme yapmışlar kullandığı ORM propel’in hantallığının ve kimi kurgu eksiklikleri nedeniyle.. Dolayısıyla asıl neden büyük ihtimalle bir şirketin altındaki proje olmaması dolayısıyla tamamen özgür bir topluluğa sahip olması.
Ağustos 30th, 2008 @ 6:32 am
Merbaha Gökçe, Zend’i kullanmakta hala ısrarlıyım, Projenin alt yapsının Zend’de kullanmamın sebebi ileriye dönük olmasıydı.
Malumun sen X7 kullanıyorsun ben G5 :)
Ben isteğime uygun bir bootstrap alıp ZF’yide şu anlık arkama aldım ama şu var ki sıfırdan ZF kullanmaktansa CI kullanmak tabiki daha hızlı olacaktır.
Benim her site için kullanacağım bir standart bootStrap oluşturmak tı ki onuda oluşturdum :)
Gerçi bayağı bir ağladım ama sonunda başardım :)
Neden uzun sürdü diye soracak olursanız Gökçe’nin de bahsettiği gibi kurgu meselesi çok önemli bir husus. Kurgunuzu güzel yapmanız ve performansınıza dikkat etmeniz gerekmekte.
Yoksa basic bir şekildede bootStrap’i gerçekleştirebiliriz.
Eylül 4th, 2008 @ 3:59 pm
Kohana’yı inceleme şansınız oldu mu? CI temel alınarak geliştirilmiş ve dediklerine göre CI’nin eksik veya yetersiz olduğu kısımları iyileştirmiş.
Eylül 16th, 2008 @ 2:05 pm
Çok ayrıntılı olmasa da inceledim, manuali ve api dökümantasyonu gayet iyi ve kötü kurgulanmış CI componentlarından uzaklaştırılmış. Ayrıca Code Igniter’ın “örnek” modelinde $_POST olduğunu düşününce, kurgusal olarak da daha iyi düşünülmüş ve uygulamış olduğunu sanıyorum. Hem de şirket tarafından değil, serbest bir geliştirici topluluğuna sahip. Kesinlikle adam kılık inceleyeceğim, o zaman notlarımı sizinle de paylaşırım.
Kasım 18th, 2008 @ 1:11 pm
Çok Güzel Böyle makaleler daha çok paylaşırsanız minnettar oluruz.
Aralık 27th, 2008 @ 6:09 pm
[...] alıntı : Framework’lere başlarken « Gökçe’nin Web Güncesi (gwg) [...]
Nisan 21st, 2009 @ 2:52 am
[...] arasında tercih yapmak üzere araştırma yaparken Gökçe Yalçın ın günlüğünde şu yazıyı gördüm. Kararsız kalanlar için birebir. Leave a comment | Trackback No comments [...]
Temmuz 2nd, 2009 @ 11:17 am
Merhaba gökçe ;
Her yiğidin yoğurt yiyişi farklıda olsa, genel olarak ortada bi kanı vardır. Buda Zf nin profesyonel adamların işi olduğudur kuşkusuz. Ama Zf , ilk anda biraz korkutucu olabilir mesela , ondan dolayı developer ‘ler başka framework lara yöneliyorlar. mesela http://www.phpframeworks.com/top-10-php-frameworks/ adresinde birinci CI, buda yeni başlayanlara , CI veya cake nin kolay olmasıdır.
@Murat Beşer: abicim :) bana hep der Zend kullan , aynı yoldayız murat abi :P
Makale için teşekkürler
Temmuz 22nd, 2009 @ 3:15 pm
@Gökhan :) Gerektiği yerde gerekeni kullan :)
Ağustos 17th, 2009 @ 6:51 pm
Merhaba Gökçe çalışmalarında kolaylıklar ve başarıların devamını dilerim.
Benim aklıma takılan bir ka. husus var bunlardan biride Framework. Eskiden ihtiyaca göre sınıflar yazıp fonksiyonlar oluşturup site yapıyordum lakin artık bu işler sıkmaya başladı beni o kadar çok sınıf ve fonksiyon yazdım ki ne nerede ne için olduğunu karıştırır oldum. Şimdi oturup kendime bir alet çantası (Framework) yapmak istiyorum , burada nasıl bir yapıda başlamalıyım en basitten neler olması gerekir ?
Ağustos 17th, 2009 @ 7:24 pm
Teşekkürler, yardımcı olabilirsem ne mutlu.
Öncelikle frameworkden kastınızın, MVC uygulamalı bir framework olduğunu farzediyorum ve özel kendiniz için yazacağınız bir frameworkün limitlerini en iyi kendinizin bileceğinizi söylemeliyim, nitekim piyasadaki frameworkler genel kullanıma açık olduğundan üç gruba ayrılıyor:
1- Temeline* el atan frameworkler: Kohana, Code Igniter, Agavi vb
Sadece uygulamanın iskeletini gösterir, basit bir MVC sınıf ve neredeyse her orta boy projede kullanılan araçları üretmeyi hedefler. Arkasında ihtiyacınıza göre kolayca genişletilebilir bir yapı bırakmayı hedefler.
2- Herşeye el atan frameworkler: Zend Framework, Symfony
Temel uygulama yapı taşları dahil, bir uygulamada kullanmak isteyeceğiniz her aracı içinde barındırmayı hedeflerler. XML okuyucu, veri çevirici, veri kaşeleme, text captcha ( dikkat, resim değil ) ‘dan, Flickr gibi özel RESFUL API servisleri kullanma ve yaratmaya kadar araç sunarlar. Bunlara karşılık, “her yapıya uygun” şekil vermeniz gerektiği için kimi sınıflarında yüzlerce ayar opsiyonu yapmanızı beklerler. Dolayısıyla işinizi bir framework ve tek bir kod standardı ile kullanırsınız, fakat işiniz kodlamaktan çok tanımlamaya yaklaşır. Çok özel işlerde kendi sınıflarınızı yazarak ve mevcut sınıfları genişletilmesine olanak verir, fakat temeliyle ilgilenen frameworklerdeki gibi özgür olamazsınız.
3-Sihir manyağı, Ruby:RoR idollü frameworkler: cakePHP, ..
Sizi, uygulamanız üzerinde uğraşırken, sizi kod yazma – mantık kurma araçlarıyla donatır. Havalı gibi görünse de bu araçların zayıf olması veya arkaplanda dönen işlevlerden bi haber olma durumu, çoğu zaman projeyi performans sorunlarında başınızı ağrıtabilir.
Benim önerilerim;
-illa ki baştan yazmak istiyorsanız mutlaka ana PHP geliştiricilerinden Rasmus’un ‘no framework MVC framework‘ adlı makalesini okumanız.
-eğer orta-çaplı projeler yürütüyorsanız 1. gruptaki frameworklerin üzerine kendi çerçevenizi kurmanız ve onunla çalışmanız. (zaten onların genel kullanım amacı bu)
-eğer büyük-çaplı projeleriniz sıklıktaysa, sıkı bir bootstrap hazırlayıp, biraz idmanla ZF veya Symfony kullanmanız. (burada önemli olan, bir öncekinin tersine frameworkün içine ne kadar kendi kodlarınızı yedirdiğiniz değil, mevcut yapıyla barışık olmaya alışmaktan geçiyor, zaten yaptığınız hemen hemen herşey bu frameworklerde mevcut)
-eğer küçük-orta projeleriniz varsa, smarty gibi iyi bi TE ve sizin en çok sevdiğiniz sınıflarınız ile devam etmek. (büyük ve çok kişili çalışmalar haricinde ve büyük geliştirici/programcı hataları olmadığı sürece satır satır bildiğiniz, yazdığınız kodlar size en iyi verimi sağlayacaktır.)
- olabildiğince 3. gruptan (cakePHP, vb) uzakta durmanız.
mutlu kodlamalar
Ocak 20th, 2010 @ 7:13 pm
yakında code igniter dan türeyen bir php5 türk yapımı framework olacak, gayet esnek ve içinde PDO barıdırıyor PDO class CI active record ile birleştirildi.Code Igniter ın uzun class methodları bile en minimale indirildi… çok yakında ..:)
http://develturk.com
tttp://obullo.com
Ocak 20th, 2010 @ 7:39 pm
Ortalık framework cenneti oldu, umarım aralarından sıyrılıp istediğin taban geliştirici topluluğunu yakalarsın. CI’dan birşey implement edeceksen, lisanslarına dikkat et derim. Kohana boşuna bütün base kodunu boşuna baştan yazmıyor..
Şubat 7th, 2010 @ 10:06 pm
core u bayağı değiştirdim loader controller ve model içinde static olarak yüklenebiliyor.Bir hak iddia edebileceklerini zannetmiyorum.Saol uyarın için.