Yeni Kayıt
Konudaki Resimler
|
Hızlı 
Bildirim
polimorfizm olmadan interface yaklaşımı
Sıcak Fırsatlarda Tıklananlar
Editörün Seçtiği Fırsatlar
Sony WH-CH520 Kablosuz Bluetooth Kulaklık - Hızlı Şarj Fonksiyonlu 50 Saate Kadar Pil Ömrü - Kulak Üstü Model - Siyah : Amazon.com.tr: Elektronik
https://www.amazon.com.tr/gp/aw/d/B0BTJD6LCL
4 sa. önce paylaşıldı
Daha Fazla 
Bu Konudaki Kullanıcılar:
Daha Az 
2 Misafir (1 Mobil) - 1 Masaüstü, 
1 Mobil
1 Mobil
Giriş
Mesaj
-
-
Classı gizlemek için yapmışlardır. Sadece Dao özelliğinin kullanılmasına izin verildiği yerlerde kullanıma interface ile sunulmuştur. Kullanıcı EmployeeDao ile ne yapacağını daha rahat kestirebilir ve ayrıca asıl classı bozmamış olur(en azından reflection kullanmadan böyle).
Belki de Dao özelliklerinin kullanılmasının zorunlu olmasını istemişlerdir. Kimse kafasına göre değiştirmesin diye. Interface olmasaydı, virtual olarak kalsaydı implement edilmeme şansı vardı ama zorla implemente etmelerini istemişlerdir bu yolla. Yoksa proje çalışmasın daha iyi demişlerdir. -
Anladım, ben genelde dao katmanınıa şu şekilde oluşturuyorum:
public abstract class AbstractDao<T extends IEntity>{
//hepsi icin ortak crud islemleri
}
public class EmployeeDao<Employee>{
//employee ya ozel islemler
}
public class CompanyDao<Company>{
///Company e ozel islemler
}
bu sekilde ortak islemler icin uste bi abstact class yaziyorum aşşağıda bunu kalıtıyorum.(hepsi icin birda crud yazmıyorum)
bu durum için de EmployeeDao ve CompanyDao için interfaceler yazmam gerekir mi? -
EmployeeDao interface'ini birden fazla concrete class implemente edebilsin diye. Spring konfigurasyonunda bu interface'i implement edecek olan class'i belirtirsin. Boylelikle DAO'ya ihtiyac duyan sistemin ust katmanlari alt tarafta ne oldugundan daha bagimsiz olmus olurlar. "Program to interface" prensibi aslinda burada olan. Spring inject ederken o interface icin hangi concrete class 'i kullanacagina runtime'da karar veriyor.
Eger yarin bir gun farkli bir database'e daha employee kaydi yapmak gerekirse sistemin bir bolumunde; yeni bir EmployeeDao class'i olusturup sadece gerekli yerlere bunu inject etmek yeterli olacak. Ama boyle bir sey hic ongorulmuyorsa aslinda sadece kod kalabaligi. Cunku concrete class'a da @Repository diyerek interface i aradan cikarip daha seri sekilde yazmak da mumkun.
DAO objeleri icin belki buna fazla gerek yoktur ama API cagiran @Service componentleri icin bu cok mantikli. Cunku 3-4 senelik projelerde kesinlikle o API'ler degisir, metod signature'lari degisir ; bu sebeple interface uzerinden kodlamak ve birden fazla implementor kullanmak sistemi daha cevik yapiyor.
< Bu ileti tablet sürüm kullanılarak atıldı >
-
teşekkür ederim, birde dao katmanında olduğu gibi service katmamnında da her bir model için sınıf oluşturmam gerekir mi? -
quote:
Orijinalden alıntı: Charizard_11
teşekkür ederim, birde dao katmanında olduğu gibi service katmamnında da her bir model için sınıf oluşturmam gerekir mi?
Her bir model icin sinif olusturmam gerekir mi derken, her service icin bir tane interface bir tane de implemente eden class olusturmam gerekir mi diye sormak istiyorsun sanirim ?
Eger oyleyse bu senin projene bagli biraz. Normalde dedigim gibi o servisler kesinlikle degisirler. Ornegin text translate eden bir servisin var. Bunun icin de googleTranslate API'si kullaniyorsun. GoogleTranslateService diye @Service class'i olusturmaktansa;
TranslationService diye bir @Interface olusturup; bunu implemente eden farkli alt servisler yapmak daha mantikli. Boylelikle ornegin tek kelimelik translation yapmak istediginde ( Ornegin Microsoft Bing de tek kelimelik translate de cok basarili ) Bing uzerinden dependencyInjection yaparsin; ama uzun bir text ceviriyorsan googleTranslationService 'i inject edersin. Bu biraz sana kalmis. Zaruri degil, gereksiz yere x2 tane class olusturup over-engineering yapmak istemeyebilirsin : ) Spring bu konuda esnek.
< Bu ileti tablet sürüm kullanılarak atıldı >
-
Mephalay
M
kullanıcısına yanıt
hayır hocam bahsettiğim şey, örnek olarak domain layerda: Employee,Company ve Departman var.Bunlar IEntity interface'ini implemente ediyorlar
DAO katmanınıda su sekilde simule ediyorum :
public abstract class AbstractDao<T extends IEntity>{
//hepsi icin ortak crud islemleri
}
public class EmployeeDao extends AbstractDao<Employee> {
//employee ya ozel islemler
}
public class CompanyDao extends AbstractDao<Company>{
//Company e ozel islemler
}
public class DepartmentDao extends AbstractDao<Department>{
//Department e ozel islemler
}
Service layer için de , dao layer da olduğu gibi yukarı bir abstact sınıf cekip Her bir domain için service sınıfı oluşturmak doğrumudur?
ayrıca dao nun bu sekilde simule edilmesi sizce mantıklı mıdır?
-
Charizard_11
C
kullanıcısına yanıt
DAO icin bu yaptigin mantikli. CRUD islemlerinde spesifik bir sey gerekirse override edersin.
Servis icin bunu nasil yapacaksin ki ? DAO'da oldugu gibi ortak bir islem olmasi gerekiyor servisler arasinda. Belki bu dao objelerinin CRUD islemleri icin genel bir Abstract class yazabilirsin, DAO'nun CRUD metodlarini delegate ederek ama bence gerek yok.
Ya da servisler icin genel bir Wrapper class'i olusturabilirsin, ServiceResponse seklinde ve bir tane abstract class olur, ServiceResponse doner. Onun icini doldurursun. Loglamak icin vs kolaylik olabilir. Ama bunun disinda acikcasi aklima servisleri generic yapacak bir yaklasim gelmiyor.
Bir baska yaklasim da DAO objeleri ile servisler arasina CacheManager tarzinda bir layer daha koymak. Buna ihtiyacin var mi bilmiyorum ama bazi objeleri cacheten return edip, bazilarini DB'den return edebilirsin. Ust katmanlarin bu detayi bilmelerine gerek yok. Bunu da senin yaptigin gibi CRUD'u implement eden bir abstact class ile yapabilirsin.
Bu arada tum bunlari yaparken su hataya dusme :https://stackoverflow.com/questions/1866794/naming-classes-how-to-avoid-calling-everything-a-whatevermanager
Boyle katman katman ayirdigin sistemlerde organizasyonu yapacak kismin da guzel ayrilmasi gerekiyor. GodObject anti-patterni olmasin sonra : )
https://blog.decayingcode.com/post/anti-pattern-god-object/
< Bu mesaj bu kişi tarafından değiştirildi Mephalay -- 27 Haziran 2017; 6:38:32 >
< Bu ileti tablet sürüm kullanılarak atıldı >
-
Şimdi anladım hocam, ilgi ve alakanız için çok teşekkür ederim . -
quote:
Orijinalden alıntı: Charizard_11
teşekkür ederim, birde dao katmanında olduğu gibi service katmamnında da her bir model için sınıf oluşturmam gerekir mi?
Merhaba,
Mephalay detayli cevap vermis zaten, bu soruya bir sey eklemek istedim sadece.
Eger spring kullaniyorsaniz, veri katmani icin spring-data (http://projects.spring.io/spring-data/ ) projesine goz atabilirsiniz. Ozetle projede dao/repository icin farkli veri kaynaklarina gore implementasyonlar mevcut. DSL destegi de var (https://docs.spring.io/spring-data/jpa/docs/current/reference/html/#core.extensions.querydsl ) basit crud islemleri/sorgular icin interfacede method signatureleri uygun sekilde tanimlarsaniz implementasyon siniflari runtime'da spring tarafindan yaratiliyor. Yine interfacelerde annotationlar ile query tanimlayabiliyorsunuz bunlarin implementasyonlarini spring hallediyor vs.
Eger ugrastiginiz projede cok spesifik sorgulara/islemlere ihtiyaciniz yoksa gayet kullanisli.
-
bestanealtcizgi
B
kullanıcısına yanıt
yonlendirmeniz için teşekkür ederim,bahsettiğiniz şeyleri araştırdım,işleri gerçekten çok kolaylaştırmışlar :), method signature lerine gore analiz etmesi falan mukemmel
< Bu mesaj bu kişi tarafından değiştirildi Charizard_11 -- 29 Haziran 2017; 4:17:36 >
Sayfa:
1
Ip işlemleri
Bu mesaj IP'si ile atılan mesajları ara Bu kullanıcının son IP'si ile atılan mesajları ara Bu mesaj IP'si ile kullanıcı ara Bu kullanıcının son IP'si ile kullanıcı ara
KAPAT X
Bu mesaj IP'si ile atılan mesajları ara Bu kullanıcının son IP'si ile atılan mesajları ara Bu mesaj IP'si ile kullanıcı ara Bu kullanıcının son IP'si ile kullanıcı ara
KAPAT X
