Buradaki bir sorun da su mesela burada hangisinin servis hangisinin repository oldugunu nasıl anlayabilirim? Misal soyle diyelim ki GetUserById adinda bir fonksiyonum var bunun servis katmaninda olmasi icin belirli bir standartta olmasi lazim mi? Mesela diyelim ki icerisine aldigi Parametrenin farkliligi bunun oldugu yeri etkiler mi? Abi vallahi cok zorlandim ya hiçbir şey anlayamiyorum karnim da AC degil ne bileyim video izledim Gemini Pro'ya sordum yazi okudum size sordum yine de kafamda bir şey oturmadi. Aslinda aklima eski kodlarim geldi GitHub repomdan biraz okuma yaptim. Abi soyle bir senaryo dogru mu repisotorymde kullanici ekleme kodum var bir de kullanicinin olup olmadigini dogrulama kodum var. Servisimde kullanici ekleme diye bir servis yazdim burada Ilk olarak repositorymdeki kodu cagirsam bu kullanicinin kayitli olup olmadigini ogrenmek icin sonrasinda eger bu kullanici kayitli degilse yine repositorymden kayit olma fonksiyonunu cagirip burada servisim uzerinden repository kodlarimi cagirip da bu implementasyonu yapmam dogru bir senaryo mu?
Oncelikle service - repo ayrimi proje yapilirken kararlastirilir. Stereotipik seyler bunlar, yani kesinligi yok. Esnetebilirsin. Hatta bu yuzden Spring'deki paket isimleri de
stereotype
altindadir. (
link )
Genel olarak projenin gerektirdigi bir "business requirement" olur; yani projenin hizmet ettigi cozume yonelik algoritmalarin, fonksiyonlarin butunu. Iste burasi servis katmaninda yer alir. Ornegin biz bir forum gelistiriyoruz seninle, Acimasizkopat adi altinda, gramer hatasi yapan kullaniciyi siliyoruz. Iste bu kontrolu yapan fonksiyon servis katmaninda olacak. Cunku is gereksinimi bu. Ancak kullaniciyi DB'den silen fonksiyon
repository
katmaninda olacak. Cunku veri islemine de o arkadas bakiyor.
Repository katmani data manipule ettigin katman. Burada isle ilgili hicbir mantik bulunmamali ( cunku o servise ait ). Ona sil dersin siler. Getir dersin getirir. O nereden getirecegini bilir ama neden getirecegini bilmez. Sen neden getirdigini bilirsin, nereden getirdigini bilmezsin. Boyle bir mantiksal ayrim olusur.
GetUserById
fonksiyonu, repository'de de olabilir; servis tarafinda da. Servisler birbirlerinden kullanici isteyebilirler ve
UserService
seklinde bir servisin varsa uygulamada kullanicidan bu arkadas sorumludur. Diger servisler direkt bundan kullanici isteyebilirler repository'den istemek yerine.
Ayrica repository katmaninda gelen bilgi, persist edilmis bilgidir, bunu
genelde direkt servis katmani disina cikarmak istemeyiz. Bu bilgiye bazi islemler uygulayamak gerekir, ornegin kullanici isminin saklanmasi ya da bazi alanlarin degistirilmesi vs gibi. Bu islemler de yine servis katmaninda yer alir.
Umarim aciklayabilmisimdir; aslinda dusunursek N-tier cafcafli gibi gorunse de sadece kodu mantiksal olarak parcalara ayirmaktan baska bir sey degil. Data bir yerde, servis bir yerde, reprezentasyon bir yerde. Elbette dogru gelistirilmis bir N-tier uygulamada katmanlar hiyerarsileri disinda kod cagiramazlar. Ornegin
repository
servis katmanindan bir sey isteyemez. Servis repo'ya emir verir, diger servislere emir verir ama
controller
cagiramaz. Eger hiyerarsi ve katman arasi cagirim yaparsan tier mimarinin de icinden gecmis oluyorsun.
Burada nihai amac kodu bolumlere ayirip, kompleksiteyle mucadele etmek.