Laravel Uygulamaları Neden Kötü Hale Getirir ?
- Aslında burada kötü olan laravel değil geleneksel yazılımcı kafasıdır.
İnsanlar Laravel uygulamalarının iyi kullanılamadığını söylerler, ancak bir süre Laravel ile çalıştıktan ve birçok projeyi gözden geçirdikten sonra, Laravel’den kaynaklı olmadığını düşünüyorum. Aslında Laravel ile harika uygulamalar yapabilirsiniz, ancak Symonfy ile başarılı olmak Laravel kullanmaktan daha kolaydır. Neden Laravel? Laravel “Adeta Metropol”.
Ölçeklenebilir(scalable) uygulamalar oluşturmak için DDD veya Hexagonal mimarisine olan ihtiyaçtan bahsetmeyeceğim. DDD’yi tercih etsem de bu konu hakkında çok fazla tartışma var ve ben sadece klasik MVC’ye odaklanmak istiyorum.
Diyelim ki bir Ürün Meodelimiz var.
class Product extends Model
{
protected $fillable = [
‘id’,
‘title’,
‘price’
];
Ve bu koda sahip bir Kontrolümüz var:
public function updateOrCreate($ean, $title, $price)
{
$product = Product::query()->where(['ean' => $ean])->first();
if (null === $product) {
Product::make(['ean' => $ean, 'title' => $title, 'price' => $price]);
} else {
$product->ean = $ean;
$product->title = $title;
$product->price = $price;
$product->save();
}
}
Daha sonra DataBase’de fiyatı olmayan ürünler olduğunu gördük ve sorunun nedenini bulmak istiyoruz.
Bunu bir kodla, IDE’den (Phpstorm veya VS) Ürünlerin nerede oluşturulduğunu ve fiyatın nerede belirlendiğini bulmasını isteyemeyiz.
Bunun bir Laravel problemi olmadığını söyleyebilirsiniz, çünkü her çerçevede aynı problemi yaşayabilirsiniz… öyle değil.
Bunu düzeltelim, daha güvenli yapalım:
/**
* @property string $ean
* @property string $title
* @property float $price
* @method static self make(array $data)
*/
class Product extends Model
İlk olarak, modelin özelliklerini belirteceğiz. Laravel’de isteğe bağlı, Symfony’de ve Yii2'de zorunludur.
Bir sonraki şey, yöntemin var olduğunu belirtmektir .
Bununla, IDE nerede ::make kullanıldığını ve fiyatın nerede ayarlanıp okunduğunu bilir.
Devam edelim:
/** @var Product|null $product */
$product = Product:: query ()->where(['ean' => $ean])->first();
IDE’ye $product öğesinin bir Product veya null olduğunu söylememiz gerekiyor, çünkü first() dönüş türünü belirtmedi.
Her model için özel bir QueryBuilder oluşturabiliriz, böylece onu her kullandığımızda yorum yapmamıza gerek kalmaz.
Büyük uygulamalar geliştirirken temel sorun nedir?
Büyük uygulamalarla ilgili asıl sorun, gelecekte çok fazla değişiklik ve tabii ki daha fazla sorun yaşama şanslarının daha fazla olmasıdır.
Bu nedenle, büyük bir uygulama geliştirmek karmaşık değildir, asıl sorun onu zaman içinde sürdürmektir.
100 modele, tonlarca denetleyiciye sahip olduğunuzu ve IDE’nin bulamadığı 20 yerde $price özelliğinizin değiştiğini keşfettiğinizi hayal edin. Sorunu çözmek için günlerinizi harcayabilirsiniz.
Peki ya yeni bir özellik eklemeye ne dersiniz?
Modelin nerede kullanıldığını bilmiyorsanız, yaptığınız şeyin etkisini nasıl biliyorsunuz?
Özet
Laravel, uygulamaları geliştirmek için fena değil, ancak kötü bir geliştiricinin kötü bir geliştirici olmaya devam etmesini çok daha kolay hale getiriyor.