Roni yazdıBana göre Laravelin her versiyonunda değişiklik göstermesi yazılımdaki süreklilik ilkesini kaybetmesine neden oluyor. Bir makale yada bir kiatap yada bir Tutorial bu değişikliklere göre kökten değişmiş oluyor. Yani bilgiler çöp oldu.
Bunu laravel 3 ile 4 geçişlerinde yaşadım. Daha iki yıl olmadan 4.3 gelmesi yapılan oynamaların sıklığını gösteriyor. Yani bundan sonra her 6 ayda bir laraveli yeniden öğreneceğiz. Öğrenip yazdıklarımızı sileceğiz.

Neyse gülü seven dikenine katlanır.

Laravel ile ilgili hiçbir gelişmeyi, Laravel geliştiricilerinin ekseriyetle kullandığı desenleri ve prensipleri (repository pattern, open closed principle, single responsibility vs. gibi) takip etmiyorsanız, en yenisi senesini dolduralı çok olan bilgileriniz çöp olacak ki bir zahmet olsun, zaten. Yazılım, gelişen teknolojilere bağlı olarak sürekli gelişiyor ve değişiyor. Laravel de bu yeniliklere son hızıyla uyum sağlıyor. En basitinden github üzerindeki Laravel projelerine bakarsanız app/ klasörü içerisinde tipik olarak uygulamanın adını taşıyan bir klasör olduğunu, yazılan kodun %90'ının o klasörde olduğunu, ve çoğunlukla repository pattern kullanıldığını göreceksiniz. Siz bu uygulamalara aşina değilseniz ve öğrenmek için de bir çaba göstermiyorsanız, her yeni sürümle bu tür zorlukları yaşarsınız ki bu Laravel'in suçu değil.

Laravel 4.3 ile bu ayrı klasör oluşturma mantığı fevkalade kolay bir hale getirilmiş. Özellikle, form doğrulamaları harika olmuş. Zira, zaten Validator sınıfını her seferinde controller'larda çağırmak gibi absürd bir uygulamaya kimse yanaşmıyor. Ayrı paketleri kullanmak ya da kendi sınıfınızı yazmak yerine direkt sadece form kurallarını belirliyorsunuz.

Yani, kullandığınız bir framework'te bir değişiklik olduğunda "bilgiler çöp oldu" diyorsanız, sizin bilgileriniz zaten çöptür ya da çöpe gitmeye layıktır. Üzülmeye değecek bir şey yok. Yenilikleri takip etmek lazım.

Kütüphanelerin ve frameworklerin çok hızlı değişmesi iyi bir şey değildir. Özellikler geri uyumluluk sorunları yaşanır ve üstüne kararsızlıklar ortaya çıkarsa bizler için chennemin kapıları açılır.
@Roni ile benzer düşünceleri paylaşıyorum.

Az önce laravel 4.2'de yine bir hata ile karşılaştım. SqlLite'da şema yapıcı ile colon silinemiyor. Hatalara baktım 1-2 yıllık mevzuyuş. Yani halen çözümü yok. Bir günüm çöpe gitti..

Roni yazdı@Mecit
Demek bizim bilgilerimiz zaten çöpmüş !! yahu sen hangi akılla programlama yapıyorsun? Yazılımda süreklik kavramının ne olduğunu biliyormusun? 4.0 ile hazırladığın projen 4.3 de çalışabilecek mi? Çalışmadı, hadi projeyi yenidenmi yazayım diyeceksin? Peki insanların onca emekle hazırldaıkları bilgiler?
Yenilikler olmalıdır, ama sizin bahsettiğiniz biçimde değil. Versiyon değişiklikleri var olan aksaklıklar, açıklar, ve ek yeni özellikler içermelidir. Bu yeni ekler sizin daha önce hazırldağınız projenizde bir aksaklığa neden olmamalıdır. Yeni gelişmeleri kullanmak isterseniz projenize sadece bu yenilikleri yansıtırsınız.
Laravel henüz oturmamış bir projedir. Sürekli köklü değişiklikler bunun bir kanıtıdır. Bu durum karşısında bizim bilgilerimizin zaten çöp olduğu sonucunu çıkardın ya bir kez daha şaşırdım. O zaman 4.4 de şuan yazdıklarımızda çöp olacak.

Neyse, siz anlaşılan çöplükte yaşamaya alışmışsınız ne diyeyim.

Öncelikle, lütfen, sakin olun. Ben şahsi olarak sizin Laravel/PHP bilginize bir şey demedim. Kendi bilgisinden/yazdığı koddan "çöp olacak" diye bahseden sizsiniz. Ben genel olarak konuşuyordum. Biraz daha açmak gerekirse;

4.0 ile hazırladığın projen 4.3 de çalışabilecek mi? Çalışmadı, hadi projeyi yenidenmi yazayım diyeceksin?

4.0'dan 4.1'e, 4.1'den 4.2'ye geçerken yazılan kodlarda köklü değişikliklere gitmeyi gerektiren bir değişim olmadı. Sadece gelen yeni özellikleri entegre edebilmek için eklenen/çıkarılan dosyalar oldu ya da bazı tekniklerin uygulama şekilleri değişti. Mesela, soft delete kullanırken, değişken yerine trait kullanmak gibi. Bu değişiklikler sizin projenizi oluşturmak için yazdığınız kodu etkileyen şeyler değil.

Size şu konuda hak verebilirim, 4.1'den 4.2'ye geçmek ile 4.2'den 4.3'e geçmek arasında büyük farklar olacak çünkü framework'ün klasör yapısı köklü bir değişikliğe gitmiş fakat önceki mesajımda demek istediğim şuydu: (Bu arada, not: Taylor Otwell, Twitter'da yeni sürümü 4.3 olarak mı yoksa 5 olarak mı çıksın diye fikir almıştı. Son durum ne bilmiyorum, takip etmedim ama büyük ihtimal 4.3 olarak çıkacak son sürüm)

https://github.com/LaravelIO/laravel.io/

Örnek olarak bu projeye bakabilirsiniz. app klasörü içerisinde Lio klasörü oluşturulup PSR-0 ile yüklenmek suretiyle kodun büyük bir kısmı (controllers hariç neredeyse tamamı) bu klasör içinde bulunuyor. Bu uygulama şekli belli bir ölçeğin üzerindeki Laravel uygulamalarında çok sık görülen bir durum. Yeni sürümde bu uygulama göz önünde bulundurularak, "yahu bu insanlar zaten uygulamalarını bu şekilde yapılandırıyor, biz de halihazırda öyle yapalım, boşuna ayrı yeten buna vakit harcanmasın" düşüncesiyle böyle bir değişikliğe gidilmiş olması ortada. Yani kısacası, demek istediğim şu ki, bu tür modern uygulamalardan haberdarsanız ve uyguluyorsanız (ki uygulamanız gerekir), zaten büyük sıkıntılar yaşamayacaksınız. Sıkıntı yaşamak şöyle dursun, daha da işinize gelen bir durum olmalı, bu.

Laravel'in oturmamış bir framework olması konusunda kısmen haklısınız fakat düşünecek olduktan sonra PHP'nin kendisi bile tam olarak oturmuş bir dil değil. Sürekli değişiyor ve gelişiyor. Her sürümde yeni bir şey ekleniyor. Laravel'i de zaten çoğu framework'ten ayıran şey bu özellikleri hemen bünyesine katıyor olması. Stabilite sorunları çoğu zaman, PHP'nin sürekli getirdiği yeniliklerden kaynaklanıyor.

unstable77 yazdıBu konuya abone olunur.

@Mecit : repository pattern konusunu ASP.NET MVC de anlatan güzel bloglar var. PHP de bulamadım. Ama bunu bide PHP de anlatsan ne güzel olurdu. :D

<?php namespace Aristona\Repositories;

final class UserRepository
{

	private $user;

	public function __construct(User $user)
	{
 $this->user = $user;
	}

	public function getAllUsers()
	{
 return $this->user->all();
	}

	public function getBannedUsers()
	{
 return $this->user->where('authority', 255)->get();
	}
}

class User extends Eloquent
{
	// Tipik model
}

class UserController extends BaseController {

	private $user;

	public function __construct(UserRepository $user)
	{
 $this->user = $user;
	}

	public function index()
	{
 return \View::make('home.homepage')
 ->with('bannedUsers', $this->user->getBannedUsers());
	}
}

*Direkt tarayıcıya yazdım, test etmedim.

Verileri tuttuğun yer ile (veritabanı), kullanacağın yer arasında (controller) duplicationları ve business logici ayırmak için bir katman oluşturmaya repository deniyor. En basit haliyle buna benziyor ve ben bu şekilde kullanıyorum. Zaten çoğu Laravel geliştirici, controller - model arasına bir aracı katman koyuyor ve bunu app/[İsim] klasörü altında tutuyorlar.

Ben bu versiyonun Laravel 5 olarak çıkmasından yanayım. Tüm klasör yapısı değişiyor ve ve ufak bir versiyon güncellemesiymiş gibi çıkıyor.

Anlamadığım nokta, neden helper fonksiyonlar adı altında global fonksiyonlar oluşturuluyor. İyi birşey değil bu. Tamam dd() falan kabul edilebilir helper olarak ama classlara global fonksiyonla alias vermek iyi bir kullanım değil. Bu Laraveldeki magic takıntısı nedir anlayamıyorum. Kolaylık sağlayacağız derken bad practice kullanımları teşvik ediyorlar.

Bu arada, çeviriler eksikmi yoksa yeniliklerin hepsi bu kadar mı? Major bir release için fazla değişiklik yok gibi geldi bana.

unstable77 yazdıBu konuya abone olunur.

@Mecit : repository pattern konusunu ASP.NET MVC de anlatan güzel bloglar var. PHP de bulamadım. Ama bunu bide PHP de anlatsan ne güzel olurdu.

Aristona yazdı

<?php namespace Aristona\Repositories;

final class UserRepository
{

	private $user;

	public function __construct(User $user)
	{
 $this->user = $user;
	}

	public function getAllUsers()
	{
 return $this->user->all();
	}

	public function getBannedUsers()
	{
 return $this->user->where('authority', 255)->get();
	}
}

class User extends Eloquent
{
	// Tipik model
}

class UserController extends BaseController {

	private $user;

	public function __construct(UserRepository $user)
	{
 $this->user = $user;
	}

	public function index()
	{
 return \View::make('home.homepage')
 ->with('bannedUsers', $this->user->getBannedUsers());
	}
}

Repository Pattern, temel olarak bu şekilde uygulanıyor. Yazdığınız sınıfı, controller'in __construct metodunda depency injection aracılığı ile çağırıyorsunuz (Laravel 5'te controller içindeki istediğiniz metotta injection yapabiliyor olacaksınız). Bu sayede hem veritabanı esnekliği sağlanıyor, hem de yazılan kod test edilebilir hale geliyor. Tabii, yukarıdaki örnek bir adım daha öteye götürülebilir. Doğrudan sınıfı inject etmek yerine arayüz (interface) yazarsınız ve UserRpository bu arayüzü implement eder. Daha sonra bir service provider yazarak bu arayüzü bu sınıf ile ilişkilendirirsiniz. (Laravel'in bind metodunu kullanarak). Başka bir veritabanına geçmek istediğinizde, bu arayüz inject edildiğinde kullanılmasını istediğiniz veritabanını bu arayüzle ilişkilendirirsiniz ve tek hamlede başka hiçbir şeye dokunmanız gerekmeden, misal MySQL'den Mongo'ya geçiş sağlayabilirsiniz. Github'daki çeşitli laravel projelerine bakabilirsiniz. Mesela, laravel-tricks bu deseni güzel bir şekilde uyguluyor.

Evet Method Injection ama bu Injection işleminin route ile birlikte nasıl yapıldığını merak etmiştim. Sınıfları inceledim ve ReflectionClass ile yapıldığını gördüm.

class Y { 
 public function test()
 {
 return 23;
 } 
}

class X
{
 public function foo(Y $y)
 {
 echo $y->test();
 }

}

Normalde yukarıdaki X sınıfının foo metodunu çağırabilmek için aşağıdaki gibi kodlanması gerekir.

$x = new X();
$x->foo(new Y);

Ama route bu işlemi otomatik yapıyor.