Sigortam.net Entity Framework Core Dönüşümü
Bu yazımda Sigortam.net 2023 teknik dönüşüm hedefleri kapsamındaki Entity Framework Core dönüşüm sürecini aktarmaya çalışacağım. Yazının genel hatlarında ise; bu dönüşüme ihtiyaç duyulmasının nedenlerini, dönüşüm için atılması gereken adımları, dönüşüm sırasında yaşadığımız zorlukların neler olduğunu, mevcuttaki yapımız ile EF Core yapısının avantajlarını ve dezavantajlarını özetleyeceğim. Bundan önce de EF Core yapısını kısaca aktarıp kendi serüvenimizi paylaşacağım.
EF Core bir ORM(Object–relational mapping) aracıdır. ORM ise veri tabanı ilişkilerini kod tarafında yönetmemizi sağlayan bir konsepttir. ORM bize Nesne Yönelimli Programlama mantığını kullanarak veri tabanında gerçekleştirdiğimiz sorguların soyutlanmasını sağlar. Böylelikle bizi SQL sorgularından soyutlayarak kod tarafında geliştirme yapmamıza imkan verir. ORM araçları da bize veri tabanı sağlayıcımızı kolaylıkla değiştirme fırsatı tanır. Yani herhangi bir veri tabanından farklı bir veri tabanına geçmemizde ufak bir kaç ayarı değiştirmemiz yeterli olacaktır.
Microsoft tarafında ise ORM için kullanabileceğimiz araçlardan birisi Entity Framework Core’dur. EF Core iyileştirmeleri sürekli devam etmekte ve kendini geliştirerek daha efektif veri tabanı sorgulamaları yapmamıza imkan vermektedir. Bu yazıda Sigortam.net’teki bu dönüşümü aktarmaya çalıştığım için ORM ve EF Core yapısını detaylandırmayacağım.
Kod tarafına geldiğimizde ise veri iletişimi için Store Procedure’ler veri tabanında çalıştırılıp sonucu döndürülerek geliştirme yapmaktayız. İş katmanının bazı süreçlerini bu SP’ler içerisinde geliştiriyoruz.
SP geliştirerek kod tarafında çağırdığımız yapıda yaşadığımız zorluklardan bazılarına değinirsek:
- Yazılım geliştiricilerinin PL/SQL yapısının genel hatlarını öğrenmesi gerekmektedir. Yeni işe başlayan bir geliştirici eğer bu yapıyı bilmiyorsa bir öğrenme zaman maaliyeti doğurmaktadır. Yine geliştiricinin SQL bilgisi önem arz etmektedir.
- Debug etme işlemi maliyetlidir. SP içerisindeki sorgular tek tek çalıştırılarak incelenir ve bu da geliştirme hızını etkileyebilir.
- Test işlemi de yine SP veri tabanında oluşturulduktan sonra koddan çağrılarak veya veri tabanında çalıştırılarak istediğimiz sonucu verdiğinin ya da istediğimiz işlemi yaptığının kontrolü ile yapılmaktadır.
- Kod kontrol işlemi ise herhangi bir pull request mekanizması gibi olmadığı için yazılım geliştirme takım üyelerine bilgi vererek SP’nin incelenmesi gerekmektedir.
- Kod dağıtım sürecinde Sigortam.net’te farklı ortamlar için 3 veri tabanı kullanıyoruz. SP içeriği kopyalanıp diğer veri tabanında manuel derlenerek yapılıyor. Burada da otomatik bir mekanizma olmadığı için üç ortama da tek tek hata yapmadan derlememiz gerekiyor. Bazen ortam farklılıkları sonucu hata yapmaya müsait bir kod dağıtım süreci olabilir. Canlı ortamda yoğun kullanılan bir SP’de derleme yapmamız gerekirse, sistemin az kullanıldığı bir saatte manuel derlememiz gerekmektedir.
Aslında genel olarak bu sorunların çözümü ya da geliştirilmesine alternatif olarak ORM dönüşümü yapmaya karar verdik. ORM aracı olarak da Microsoft tarafında en fazla desteği gören EF Core kütüphanesini kullanarak 2023 teknik dönüşümlerden birisi olarak tüm API’ların EF Core’a taşınmasına başladık.
İşte yazımın bundan sonraki bölümünde de bu dönüşüm sürecinde Sigortam.net olarak nasıl bir yol izledik ve yazılım geliştiriciler olarak bizler nasıl ilerledik değinmek istiyorum.
Yazılım geliştirme ekibi olarak ORM ve EF Core bilgi seviyesini tüm ekipte ortak noktaya getirmek için iç eğitimler düzenledik. Bu kapsamda sunumlar ve bir API de POC çalışması yapıldı. Daha sonra kaynak doküman ve EF Core için paket geliştirerek bu paketi API’lerde referans olarak kullanmaya başladık.
Yazılım geliştirme takımındaki üyeler, görevli oldukları API’larda bu dönüşüme başlamış oldu. EF Core paketinin eklenmesiyle birlikte gerekli konfigürasyonu yaptıktan sonra en zorlayıcı kısım olarak entitylerin oluşturulması oldu. Daha sonra SP’lerin işlevini birebir yapacak sorgular ve diğer süreçleri kod tarafına taşımakla devam ettik. Bu taşıma işlemini yazının uzamaması için burada detaylandırmayacağım.
Geliştirmelerimizi tamamladıktan sonra artık herhangi bir veri tabanına bağımlılığımız da kalmamış oldu. Bir veri tabanı değişikliğinde sadece ilgili veri tabanı sağlayıcısının konfigürasyonunu yapmak yeterlidir. Ayrıca artık doğrudan SQL sorguları yazmıyor, Nesne Yönelimli Programlama yapılarını kullanarak sorgulamamızı veri tabanından soyutlayarak yapabiliyoruz.
Kod inceleme işlemini kod düzenleme aracı üzerinden adım adım yapabiliyoruz. Kod analiz işleminde artık PR’larımızı gönderiyor ve bir süreçten geçiriyoruz. Kodun ilgili ortama aktarılması sürecinde ise ilgili PR’larımız onaylandıktan sonra ortamlara otomatik olarak derleyebiliyoruz.
Aslında bu yazımda genel olarak yukarıda belirttiğim ihtiyaçlar doğrultusunda EF Core dönüşümünün bize nasıl çözüm getirdiğini aktardım. Son olarak da PL/SQL yapısının ORM yapısına göre bazı avantajlarından bahsetmek istiyorum. Eğer kod tarafındaki sorgulamalarımızda bir sorunla karşılaşırsak PR açıp düzenleme yaptıktan sonra kodun canlıya çıkması gerekiyor. SP yapısında ise canlıda bir hata ile karşılaştığımızda SP’yi hızlıca derlememize imkan sağlıyor. Bir başka avantaj olarak procedureler direkt olarak veri tabanı üzerinde çalışıyor. Procedure’ler bir kez derlendikten sonra tekrar tekrar çalıştırılabiliyor. Böylece SQL planda bazı adımlar tekrar edilmediğinden daha hızlı sonuç verebiliyor.
Yani bu dönüşümle birlikte Sigortam.net olarak veri tabanı bağlılığımızı en aza indirirken kodlarımızı da tekrar gözden geçirme imkanımız oldu. Yukarıda da bahsettiğim gibi iki yapının da avantaj ve dezavantajlarını test etme imkanı elde ettik ve Sigortam.net yazılım geliştirme ekibi olarak farklı tecrübeler edinmiş olduk.
