alt text

Özet olarak şekildeki gibi bir proje yapısı var. Repository Pattern içerisinde ORM aracı ile veritabanı işlemlerini yapıyorum. Fakat, bazı noktalarda, ORM araçlarını kullanmadan (iş kuralı gereği) saf SQL işletmem gerekiyor.

Temel CRUD (Create, Read, Update, Delete) işlemleri için ORM kullanıyorum. Fakat, veritabanı içerisinde değişiklik yapmayacağım, sadece veri çekeceğim tablolar var.

Yani uygulama üzerinden; kayıt ekleme, silme, güncelleme yapılacak tablolara ORM ile ulaşmak. Sadece raporlama için veri çekilecek tablolara ise direk SQL veya SP, Views, ... şeklinde ulaşmam gerekiyor. Belki tam anlatamadım ama kod ile anlatmaya çalışayım.

interface ICustomerRepository 
{
    public List GetCustomers();
}

CustomerRepositoryFromORM implements ICustomerRepository 
{
    public List GetCustomers()
    {
         return entity.Customers;
    }
}

CustomerRepositoryFromSQL implements ICustomerRepository 
{
    public List GetCustomers()
    {
         string query = "Select * From Customers";

         return ExecuteSQL(query);
    }
}

Yukarıdaki gibi bir yapıda Bu repository i servis e nasıl enjekte edeceğiz. Servis içerisinde normalde repository i aşağıdaki gibi enjekte ediyorum.

CustomerService implements ICustomerService
{
    private ICustomerRepository customerRepository;

    public CustomerService (ICustomerRepository _customerRepository)
    {
        this.customerRepository = _customerRepository;
    }
}

Tam anlatabildim mi bilmiyorum ama, İşin özeti resimdeki gibi bir yapı içerisinde, farklı veri kaynaklarından veri çekerken, Repository ve Service sınıflarının yapısı nasıl olmalı. Aynı interface den türeyen farklı sınıflar, en etkin şekilde nasıl enjekte edilmeli (veya bağımlılığı kaldıran farklı bir yöntem). Benim yukarıda yaptıklarımdan farklı bir yapıda olabilir. Hatta cok farklı bir mimari de (yukarıdaki mimari tercihimdir). Amacım uygulamanın, değişiklikler karşısındaki kırılganlığını en az seviyeye düşürmek. Bu konudaki tavsiyeleriniz nelerdir?

Teşekkürler.


GÜNCELLEME

Çok iyi iki tane makale buldum.

1. Dependency Injection, Unit Of Work, NHibernate (Farklı veri kaynakları için genişletilebilecek şekilde bir tasarım. Entity Framework, nHibernate, Ado.Net, ... gibi farklı veri erişimleri için genişletilebilir olarak tasarlanmış)

2. ORM araçları kullanmadan veriye erişim metodlarını Repository Pattern içerisinde nasıl kullanırız.

Özellikle ilk makale bir çok farklı konuyu aynı anda bir arada sunan bir yazı.

soruldu: 27 Ağu '13, 09:23

AliR%C4%B1za%20Ad%C4%B1yah%C5%9Fi's gravatar image

AliRıza Adıyahşi ♦
7.9k146288
cevap kabul oranı: 44%

değiştirildi: 11 Ara '13, 07:31


CustomerRepositoryFactory isminde bir sinif yapip, bu dogrudan CustomerService sinifini enjekte edilebilir. CustomerRepositoryFactory bünyesinde hem CustomerRepositoryFromORM hem de CustomerRepositoryFromSQL siniflarindan olma nesneleri tutar. Örnegin CustomerRepositoryFactory.getInstance("SQL").GetCustomers() ya da CustomerRepositoryFactory.getInstance("ORM").GetCustomers() seklinde gerekli repository implementasyonunu ulasabilabilir. Servis bu sekilde kullanacagi repository implementasyonunu secmis olur.

permanent link

cevaplandı: 27 Ağu '13, 09:39

%C3%B6zcanacar's gravatar image

özcanacar ♦♦
17.2k59183183
cevap kabul oranı: 52%

Hocam, bu tam da benim aradığım sorunun cevabı. Sizi yakalamışken bir soru daha sorayım, Peki tüm bu soruda yazdıklarım, farklı veri kaynakları ile çalışırken uygun bir yapımıdır. Uygun değilse tavsiyeleriniz nelerdir?

(27 Ağu '13, 09:50) AliRıza Adıyahşi ♦ AliR%C4%B1za%20Ad%C4%B1yah%C5%9Fi's gravatar image
4

Repository ya da DAO katmaninin olmasi uygulamayi kullanilan veri katmanindan bagimsiz bir hale getiriyor. Cogu zaman DAO'nun gereksiz oldugu, örnegin dogrudan JPA gibi ORM teknolojisinin kullanilabilecegi iddaa ediliyor, lakin bu uygulamayi yine spesifik bir teknolojiye bagimli kilmakta, bu yüzden tavsiye ettiginiz katmanli mimari tercih edilmeli. Sadece bu sekilde uygulamayi sarsmadan kullanilan ORM ya da diger veri edinme teknolojilerini degistirmek mümkün.

(27 Ağu '13, 13:12) özcanacar ♦♦ %C3%B6zcanacar's gravatar image

Bu kadar tesadüf olur ancak. Bende blogda Asp.net Membership yapısının katmansal mimaride basamakları atladığını anlatan bir yazı hazırlamayı düşünüyordum. Resmi de aşağıdaki gibi. .Net için hazırlanan hazır Membership yapısının kendi içinde veritabanı erişimi mevcut.

alt text

permanent link

cevaplandı: 28 Ağu '13, 00:11

ucuncubayram's gravatar image

ucuncubayram
1.4k122840
cevap kabul oranı: 11%

Cevabınız
toggle preview

Bu soruyu takip et

E-Posta üzerinden:

Üyelik girişi yaptıktan sonra abonelik işlemlerini yapabilirsiniz

RSS üzerinden:

Cevaplar

Cevaplar ve Yorumlar

Yazı Formatlama

  • *italic* ya da _italic_
  • **bold** ya da __bold__
  • link:[text](http://url.com/ "başlık")
  • resim?![alt text](/path/img.jpg "başlık")
  • liste: 1. Foo 2. Bar
  • temel HTML etiketleri de kullanılabilir

Bu sorunun etiketleri:

×19
×17
×4

Soruldu: 27 Ağu '13, 09:23

Görüntüleme: 1,321 kez

Son güncelleme: 11 Ara '13, 07:31

powered by BitNami OSQA