Prisma ve Eloquent: İkisi Hakkında Nasıl Düşünmeliyiz?

Laravel’dan Prisma’ya geçiş yapıyorsanız ve iki ORM’yi ilk kez deniyorsanız, her ikisi de benzer görevleri yerine getirse de, ortada oldukça farklı bir yaklaşım var. Bu makale, her birinin verilerinizi nasıl düşündüğünü, farklılıkların neden önemli olduğunu ve kullandığınız araca uygun bir zihinsel model nasıl seçileceğine dair farkındalık oluşturmayı amaçlıyor.

En önemli fark: Gerçek nerede yaşar

Bu, içselleştirmeniz gereken en büyük noktadır.

Laravel Eloquent, gerçeği migration dosyalarında saklar.

Migrosyonları birer birer yazarsınız. Her migration bir adımdır. Veritabanınızın mevcut şekli, bunların sırasıyla çalıştırılmasının sonucudur. Model sınıfı, sütunları listelemez. İlişkiler, accessors, mutators ve doldurulabilir alanları listeler. Ancak users tablosunun hangi sütunları olduğunu öğrenmek istiyorsanız, ona dokunan son migration’ı okursunuz.

Prisma, gerçeği schema.prisma dosyasında saklar.

Veritabanınızın tüm şeklini tek bir dosyada tanımlarsınız. Modeller, alanlar, türler, ilişkiler, indeksler hepsi buradadır. prisma migrate dev komutunu çalıştırdığınızda, Prisma şemayı veritabanıyla karşılaştırır ve aradaki farkı kapatacak bir migration oluşturur. Migration dosyaları vardır ama bunlar çıktı, kaynak değildir.

Laravel tarih temellidir. Prisma ise durum temellidir.

Laravel zihinsel modeli:
  migration'lar kaynak -> çalıştırmak veritabanını üretir

Prisma zihinsel modeli:
  schema kaynak -> Prisma buradan migration'ları üretir

Bu kavramsal farklılık anlaşıldığında, diğer farklılıkların çoğu da mantıklı hale gelir.

Mükemmelist bakış açısı

Eğer verilerinizin tek bir temiz görünümünü seviyorsanız, Prisma hoşunuza gidecektir. schema.prisma dosyasını açtığınızda her şeyi görebilirsiniz: her model, her sütun, her ilişki,tek dosyada. Mevcut durumun ne olduğunu anlamak için tarihe dayalı migration dosyalarını karıştırmanıza gerek yoktur. Model sınıfının migration’dan saptığı risk yoktur. Şema dosyası cevaptır.

Laravel’de karşılaşabileceğiniz durumlar şunlardır:

• Yeni bir migration’da status sütununu eklediniz.
• status‘u modeldeki $fillable dizisine eklemeyi unuttunuz.
• Artık User::create(['status' => 'active']) bu alanı sessizce kaydetmez.

Bu tür bir sapma, Prisma’da gerçekleşemez. Şema dosyası, bir sütunu tanımladığınız tek yerdir ve oluşturulan istemci otomatik olarak her alanı bilir. Ayrı bir model sınıfını güncellemeyi hatırlamanıza gerek yoktur.

Diğer taraf: birleştirme çatışmaları

İşte Prisma kullanan ekipleri zor durumda bırakabilecek bir takas. Her şey tek bir dosyada bulunduğundan, o dosya sık kullandığınız bir nokta haline gelir. Eğer iki geliştirici aynı gün model eklerse, her iki dal da schema.prisma dosyasını düzenler ve bir birleştirme çatışması yaşarsınız.

Laravel’de bu problem nadiren ortaya çıkar. Her migration kendi tarihli dosyasıdır. İki geliştirici paralel olarak migration ekleyebilir ve Git bunları üst üste koyar. Dosyaların sırası biraz değişebilir, ancak genellikle aynı dosyada metin çatışmalarını manuel olarak çözmeniz gerekmez.

Hiçbiri yanlış değil. Farklı acılara nasıl yaklaşmanız gerektiğine dair farklı yaklaşımlardır.

Migration’ların farklı hissettirmesi

Laravel’de bir migration el yazısıyla yazdığınız bir şeydir:

Schema::create('posts', function (Blueprint $table) {
        $table->id();
        $table->string('title');
        $table->text('body');
        $table->timestamps();
    });
    

Bu dosyayı siz yazdınız. Bu sizin eseriniz. Şemayı değiştirdiğinizde, sütunları ekleyen veya değiştiren başka bir migration yazarsınız.

Prisma’da ise, şemanın yeni şekli schema.prisma dosyasına yazılır:

model Post {
      id    Int    @id @default(autoincrement())
      title String
      body  String
      createdAt DateTime @default(now())
      updatedAt DateTime @updatedAt
    }
    

Daha sonra prisma migrate dev --name add_posts komutunu çalıştırırsınız ve Prisma size SQL migration’ını yazar. neredeyse hiç migration dosyalarını el ile düzenlemezsiniz. Bunlar bir çıktıdır.

Buna güvenmeye başladığınızda özgürleştirici olabilir, ancak bunu tam olarak hissetmiyorsanız biraz rahatsız edici de olabilir. SQL üzerinde tam kontrol istiyorsanız, Laravel daha güvenli hissettirebilir. Eğer bir daha ALTER TABLE yazmamak istiyorsanız, Prisma bir nimet gibidir.

Model’lerin farklı hissettirmesi

Laravel’de model sınıfı mantığın yaşadığı yerdir:

class Post extends Model
    {
        protected $fillable = ['title', 'body'];

        public function author()
        {
            return $this->belongsTo(User::class);
        }
    }
    

İlişkiler, accessors, scopes, olaylar, dönüşümler hakkında bilgi içerir. Sütunlar, migration ve veritabanından çıkarılmıştır.

Prisma’da ise model yalnızca bir şekil tanımıdır. Genişletilecek bir sınıf yok, özel yöntem yok, scopes yok:

model Post {
      id       Int    @id @default(autoincrement())
      title    String
      body     String
      authorId Int
      author   User   @relation(fields: [authorId], references: [id])
    }
    

Davranış, veri tanımından ayrı bir uygulama kodunuzda yer alır. Bu kasıtlıdır. Prisma, şemanın yalnızca veri tanımlamasını istemektedir. Mantık, hizmetler, kontrolörler, repository’ler veya mimarinizin koyduğu her yerde bulunur.

Eğer işlev zengini olan kalın modelleri seviyorsanız, Laravel daha doğal hissedecektir. Eğer ince veriler ve mantığınızı düz fonksiyonlarda tercih ediyorsanız, Prisma daha temiz görünecektir.

Zihinsel modeli nasıl seçilir

Laravel’de çalışırken şunu düşünün:

“Veritabanındaki her değişiklik bir migration’dır. Model sınıfı, satırlarla nasıl etkileşim kurulacağını tanımlar, satırların neye benzediğini değil.”

Prisma ile çalışırken ise şunu düşünün:

“Tek bir şema dosyam var. Onu veritabanının nasıl görünmesi gerektiğini tanımlamak için düzenliyorum. Prisma bunu gerçekleştirmeyi sağlar.”

Yanlış zihinsel modeli kullanmak, çoğu hayal kırıklığının nedenidir. Prisma’yı Laravel gibi yazmak, aracıyla savaştırır. Laravel’i Prisma gibi yazmak ise migration’ların bir denetim kaydı olma noktasını kaçırır.

Küçük ipuçları

• Laravel’de, bir migration yayınlandıktan sonra asla düzenlemeyin. Yeni bir tane yazın.
• Prisma’da, oluşturulan bir migration dosyasını asla düzenlemeyin. Bunun yerine şemayı değiştirin ve Prisma’nın yeniden yazmasını sağlayın.
• Laravel’de, model ve migration’ı zihninizde senkronize tutun. Sütunlar eklediğinizde her zaman $fillable ve dönüşümlere bakın.
• Prisma’da, yoğun bir takımda yeni bir özellik üzerinde çalışmaya başladığınızda, şemayı düzenlemeden önce en son main‘i çekin, tıpkı package.json için yaptığınız gibi.

Son düşünce

Laravel’in Eloquent’i ve Prisma, stil açısından gerçekten rekabet etmiyorlar; felsefi bir yarışa girdiler. Laravel, “Yaptığınız her değişikliği takip edeceğim.” derken, Prisma “Ne istediğinizi söyleyin, ben bunu gerçekleştireceğim.” diyerek karşılık veriyor. Her ikisi de iyi çözümler. Hangisinin sizin için doğru olduğu, tarihleri kendiniz tutmayı mı yoksa aracın çıkarmasını mı tercih ettiğinize bağlıdır.

Laravel’den geliyorsanız ve Prisma’yı deniyorsanız, mükemmelist yönünüz büyük ihtimalle şemanızın tek bir yerde olmasından hoşlanacaktır. Ancak ekip arkadaşlarınızın bu dosyayı da kullandığını göz önünde bulundurarak daha dikkatli koordine olmaya hazırlıklı olun.