Arda yazdıAristona yazdı...
Teşekkürler fikirlerin için @Aristona , açıkçası biraz daha geç çıkaracaktım ama biraz da seninkiler gibi görüş alayım ona göre şekillensin dedim ve çıkarayım dedim, bazı kısımları öyle bırakmayı kasten tercih ettim. Çok kafa yormadım yani. Gelen standart yapıdan çıkmamaya ve de "hiç laravel bilmeyenin bile bakınca anlayabileceği bir yapıda" bırakmaya çalıştım.
Daha iyi olmuş erken paylaştığınız. Evet belli oluyor bazı yerlerde.
Benim önerilerim Laravel'e yeni başlamış birisi için zor gelebilir ilk etapta, bu konuda haklısınız.
Arda yazdı
Assetlerde haklısın, ama async task çok yok (admin datatables'ları haricinde hiçbir yerde yok hatta), Her şeyi ayrı js yaparsam da request sayısı artacak. Zaten production'da bu assetler sunucu yönetmeyi bilen kullanıcılarca vhost ayarlarıyla tarayıcıya cacheletileceğinden büyük bir sıkıntı olacağını ben şahsen düşünmüyorum. Ayrıca uygulama o css / js lerin en az %80'ini açılan herhangi bir sayfada kullanıyor. Bu sebeplerden biraz da bu yüzden css ve js'i tek dosyada birleştirmeye karar verdim. Aslında admin.js diye ayrı bir js yapacaktım sonra vaz geçtim. İlerde belki yapabilirim bilmiyorum. Gulp'ı zaten bu kodu yazmadan önce hiç kullanmamıştım, front-end developer arkadaşlarım hallediyordular sağ olsunlar
Projeye göre değişiyor. Yaptığın proje çok küçük ve minimalist. Benim bahsettiğim biraz daha enterprise uygulamalar için.
Benim Gulp çıkmadan önce Grunt kullanmaya başlamıştım. Komple tüm workflowumu değiştirmiştim bir günde Grunt sayesinde. Kendi Gruntfile dosyamı yazıyorken sabaha kadar çalışmıştım farkında olmadan.
Genellikle Grunt ve Gulp gibi araçların syntaxları çok basit oluyor. İstersen Laravel'de elixir var, onun syntaxı çok daha kolay.
Arda yazdı
getsTagsByID dediğin metod eğer
şuysa doğrudan veritabanıyla konuştuğu için, ve de ilerde aynı metod adı ile başka bir arkaplan işlemleri ile aynı kapıya çıkma gibi bir durumu olmadığından modelde kalmasını tercih ettim şahsen.
Repository pattern'e sokarsam bunun için biraz gereksiz işlem gibi olmaz mı sanki?
Ben modellerde sadece propertyleri/relationları/scopeleri vb. tutuyorum. O tür methodları repository içinde tutuyorum. Buna belki karşı çıkan olabilir ama öteki türlü model dosyası çok büyüyor.
Arda yazdı
Hah evet, validate'lerde haklısın, $this->validate($input, $rules) diye oluyor, hiç aklıma gelmedi oraları yazarken, L4 kafası işte, yakında bi commit gelir ona
Validator facade'ı ile de oluyor ama. Yazılan kod yanlış veya ilerde deprecate olacak bir kod/yol değil yani.
Şuan geliştirdiğim proje haricinde Laravel projesi geliştirmedim son 1 yıldır. Başladığımda Laravel 4.0 vardı, 5.0'a güncelledim çıktığı zaman, ama Form Requestleri kullanmak için büyük değişiklikler yapmam gerekiyordu o yüzden özellikle Request özelliğini fazla kullanamadım. Kendim ona benzer birşey yazmıştım. Ama bildiğim kadarıyla Form Requestlerin amacı tamamen validationla ve diğer boilerplate işlerle ilgili.
Arda yazdı
Validation kuralları için aslında ben l4'de modelde veya birden fazla yerde ortak kullanılacaksa autoload eden bir dosyada değişken / metod vs. olarak tutuyordum. Belki bunları da o şekilde da yaparım bilmiyorum. Bunun gibi ufak ebatlı uygulamada abartı kaçabilir mi acaba ?
Benim bildiğim bazı kişiler model içinde attribute oluşturup tutuyorlardı, ama o yöntem benim hoşuma gitmiyor. Öyle tutunca, mesela atıyorum resmi kategoriye ekleyecekken kategori validationunu almak için Category modeline erişmek gerekiyor. Birde şu soruya tam olarak cevap veremiyorsun. O işlem modellemi alakalı yoksa validationlamı alakalı. Nereye bakacak mesela başka bir geliştirici PR atmak için. O yüzden ben özel bir namespacede tutuyorum ruleleri. Temiz oluyor.
Arda yazdı
Model observer olabilir aslında güzel fikir (Y). Aslında ilk düşünmüştüm, ama neden bilmiyorum düşünürken sluggable da çalışırsa acaba 2 kere çalışır mı diye incelerken sonra ne yalan söyliyim amaan dedim vaz geçtim
. Yeniden denerim.
Bunları kalanları bir araya getirmek de laravel 5.1 ' e geçiş sırasında olsun
Aklına geldikçe pull request de alabilirim bu arada
Fikirlerin ve incelemen için yeniden teşekkürler!
Hepimiz aynı şeyi yapıyoruz.
Çok iyi olacak diye kendimizi fazla zorlamaya gerek yok. Zaten proje ilerledikçe atılması gereken adımları görüyorsun.
Event ve observer patterni öğrenince uygulamaya yaklaşımın biraz daha farklılaşıyor. Sanırım Laravel 5.1'den sonra Observer ile attributeleri de observe etme desteği gelecek Laravel'e. O zaman attributeleri de izleyip event bindleyebileceğiz. Örneğin users.authority değeri değiştiğinde email at gibi şeyler. Business logic dediğimiz kısımları bu eventlere listener atayarak yapmak çok iyi oluyor. (Örneğin, birisi Moderatör olduysa, Moderatör el kitabını email attırma gibi işler.) Kocaman fonksiyonun içinde if/else yazarak zorlanmıyorsun. Ne yapılması gerekiyorsa isimlerini event emittere gönderiyorsun, gerisini o hallediyor. Scale olmana da yardımcı oluyor bu yöntem. Image resize gibi resource yiyen event işlerini başka sunuculara paylaştırabiliyorsun.
Tabi bunlar benim fikirlerim, yapmak zorunda değilsin. Şu hali de iyi uygulamanın.
PR atabilirim, ama Github'u çok az kullanmaya başladım son zamanlarda, o yüzden ne zaman olur veya olurmu hiç bilmiyorum. Kendi projelerimi bile yarım bıraktım.
