REPR Design Pattern
Çok uzun bir süredir MVC modelini kullanarak web uygulamaları geliştiriyorum. Birçok farklı ekip ile çalışıyorum. Dolayısıyla, birçok farklı kültürel yaklaşım gördüm. Ve eski Web Forms yöntemiyle uygulama geliştirmeye asla geri dönmek istemememe rağmen, size şunu söyleyebilirim ki, MVC Controller ASP.NET/ASP.NET Core projelerinde çoğu zaman sorun kaynağı oluyor.
MVC Controller temelde bir anti-patern olarak görülebilir. MVC dinazor diyebilir miyiz? Bence olabilir :) Birbirini nadiren çağıran ve genellikle aynı durumu işlemeyen metodların koleksiyonudur aslında. Bir arada olmazlar. Genellikle şişerler ve kontrolden çıkarlar. Özel metodları varsa, genellikle yalnızca tek bir genel metot tarafından çağrılırlar. Çoğu geliştirici, Controller’ların mümkün olduğunca küçük olması gerektiğini kabul eder, ancak bunlar kutudan çıkan tek çözüm olduğu için, ASP.NET Core geliştiricilerinin %99.99'u MVC kullanır.
Sorunu hafifletmek için MediatR gibi araçları kullanabilirsiniz. MediatR, komutları Handler’lara yönlendiren tek satırlık Action metodlarına sahip olmanızı sağlar. Bu, daha bütüncül sınıfların elde edilmesini ve daha iyi nesne yönelimli prensipleri takip etmesini sağlar. Ancak, eğer ekstra bir yapıya bile ihtiyacınız olmadan bu sorunu çözebilseydiniz ne olurdu?
Şimdi, burada API’lerden bahsediyorum. Eğer hala sunucuda Razor ile oluşturulan HTML yanıtlarıyla tarayıcı isteklerine doğrudan yanıt veren şeyler inşa ediyorsanız, o zaman muhtemelen Razor Pages veya Blazor kullanmalısınız, çünkü ikisi de bu sorunu zaten çözmüş durumda.
Neden Bu Standart Olmayan Framework’ü Kullanmalıyım?
Aslında, API Endpointleri sadece birkaç kısıtlama ile uygulanan Controller’lardır. Yani, kelimenin tam anlamıyla, ControllerBase’den miras alırlar. Dolayısıyla, herhangi bir şekilde standart değiller ve Controller’lar ile çalışan her şey, Routing, Model View, Model Validate, Dependency Injection, Filter vb. hepsi API Endpointleri ile de sorunsuz bir şekilde çalışır çünkü, onlar da Controller’dır.
Ancak, bu kısıtlamaya ihtiyacım yok — kendim de yapabilirim!
Evet, doğru. Tek Sorumluluk Prensibini takip eden ve sadece bir şeyi yapan Controller’lar oluşturabilirsiniz. Ama yapmıyorsunuz. Kısıtlamaların(Constraints) kötü bir şey olduğunu düşünme tuzağına düşmeyin — değiller!. Kısıtlamalar, daha iyi kaliteye yol açabilecek kullanışlı bir tasarım aracıdır.
Bir yazılımda global, değiştirilebilir durumu düşünelim. Hemen hemen herkes, global durumu birçok farklı fonksiyon, sınıf ve modülden doğrudan değiştirmenin, bulunması ve düzeltilmesi zor hatalara yol açan kötü bir uygulama olduğu konusunda hemfikirdir. Bu yüzden, çoğu dil yerel değişkenler ve argümanlar için bir tür encapsulate sunar ve C# gibi çoğu nesne yönelimli dil bu konuda daha da ileri giderek private, protected ve internal gibi anahtar kelimeler kullanarak değişkenleri koruma ve kapsülleme konusunda çeşitli yollar sunar.
Ancak, bu kısıtlamalara ihtiyacımız yok — global değişkenlerimiz için sadece bir isimlendirme kuralı kullanabiliriz ve aynı işi yaparız! Tabii Constraints’in birçok faydasından yararlanamayız.
REPR Design Pattern
MVC — Model-View-Controller, UI ile çalışmak üzere tasarlanmıştır. View, bir UI bileşenidir. Eğer API’ler oluşturuyorsanız, View’lar yoktur, bu yüzden en fazla MC desenini kullanıyorsunuzdur, ya da onu Model-Action-Controller olarak adlandırabilir ve MAC deseni elde edebilirsiniz. Önemli olan, API’leriniz için zaten MVC kullanmıyorsunuz, bu yüzden daha uygun bir deseni düşünmek büyük bir çaba gerektirmemelidir.
API Endpointleri oldukça kendi içinde kapalıdır ve her biri üç bileşeni kullanarak tanımlanabilir:
Request: Endpoint’in beklediği veri şekli.
Endpoint: Bir isteğe verilen yanıt.
Response: Endpoint’i çağıran tarafa döndürdüğü yanıt.
Bu üç öğeyi bir araya getirerek, Request-EndPoint-Response ya da REPR desenini elde edersiniz.
REPR Design Pattern, MVC’den farklı olarak API geliştirmek için tasarlanmış bir yaklaşımdır. API’ler UI bileşenlerine sahip olmadığı için, MVC deseni doğrudan uygulanamaz/uygulanmamalı. Bunun yerine, REPR deseni, API’lerin özelliklerine daha uygun bir şekilde tasarlanmıştır ve her API endpoint’inin sadece üç bileşenle tanımlanmasını sağlar. Bu, kodun daha okunabilir ve anlaşılabilir olmasını sağlar.
Sonuç olarak
REPR deseni, API geliştirme sürecini basitleştirir, kodun daha düzenli hale gelmesini sağlar ve API’lerin gereksinimlerine daha uygun bir şekilde tasarlanmasını sağlar. Bu nedenle, API geliştiricileri REPR desenini kullanarak daha verimli ve etkili bir şekilde çalışabilirler.
