Mimari açıdan bakıldığında, Microsoft'un Entity Framework gibi bir veritabanı soyutlama katmanı ayrı bir Veri Erişim Katmanı ihtiyacını ortadan kaldırıyor mu?


11

Olduğu gibi

Yıllarca yazılım çözümlerimi şu şekilde organize ettim:

  • Verilere erişme işini özetlemek için Veri Erişim Katmanı (DAL)
  • İş kurallarını veri kümelerine uygulamak, kimlik doğrulamasını işlemek vb. İçin Business Logic Layer (BLL)
  • Zamanla oluşturduğum ortak yardımcı yöntemlerin bir kütüphanesi olan Utilities (Util).
  • Tabii ki web, masaüstü, mobil, ne olursa olsun Sunum Katmanı.

Şimdi olduğu gibi

Son dört yıldır Microsoft'un Entity Framework'ünü kullanıyorum (ağırlıklı olarak bir .NET geliştiriciyim) ve Entity Framework'ün zaten yapmış olduğu gerçeği nedeniyle DAL'a sahip olmanın temiz olmaktan daha hantal hale geldiğini görüyorum DAL'mın yaptığı bir iş: CRUD'ları bir veritabanında çalıştırma işini soyutlar.

Yani, tipik olarak böyle bir yöntem koleksiyonu olan bir DAL ile sonuçlanır:

public static IQueryable<SomeObject> GetObjects(){
    var db = new myDatabaseContext();
    return db.SomeObjectTable;
}

Daha sonra BLL'de bu yöntem şu şekilde kullanılır:

public static List<SomeObject> GetMyObjects(int myId){
    return DAL.GetObjects.Where(ob => op.accountId == myId).ToList();
}

Bu basit bir örnektir, çünkü BLL tipik olarak birkaç mantık satırı daha uygular, ancak böyle sınırlı bir kapsam için bir DAL'yi korumak biraz fazla gibi görünür.

Sadece DAL'den vazgeçmek ve BLL yöntemlerimi böyle yazmak daha iyi olmaz mıydı:

public static List<SomeObject> GetMyObjects(int myId){
    var db = new myDatabaseContext();
    return db.SomeObjectTable.Where(ob => op.accountId == myId).ToList();
}

Yukarıda belirtilen nedenlerle DAL'yi gelecekteki projelerden düşürmeyi düşünüyorum, ancak bunu yapmadan önce, bir projede yola çıkmadan ve yapmadığım bir problemi keşfetmeden önce burada toplumu gezme / öngörü / görüşleriniz için yoklamak istedim. t öngörmek.

Herhangi bir düşünce takdir edilmektedir.

Güncelleme

Uzlaşma ayrı bir DAL'ın gerekli olmadığı, ancak (burada kendi çıkarımımı yapma) satıcı kilitlemesini önlemek için iyi bir fikir gibi görünüyor. Örneğin, yukarıda gösterildiği gibi EF çağrılarını soyutlayan bir DAL'ım varsa, eğer Hiç başka bir satıcıya geçmek benim BLL yeniden yazmak gerekmez. Yalnızca DAL'deki bu temel sorguların yeniden yazılması gerekir. Bunu söyledikten sonra, bunun gerçekleşeceği bir senaryo öngörmeyi zor buluyorum. Zaten bir Oracle db bir EF modeli yapabilirsiniz, MSSQL verilen, MySql de (??) mümkün olduğundan eminim, bu yüzden ekstra kod hiç değerli bir ROI verecek emin değilim.


3
Veri erişim katmanınızın EF'den farkı nedir? EF bir veri erişim katmanı değil mi? İş mantığınız ve EF arasında kendi soyutunuzu korumak için görebildiğim tek neden, sınamayı daha kolay test etmek ve satıcı kilitlemesini önlemek.
Marjan Venema

2
Bu benim açımdan - benim görüşümde hiçbir fark yok, ama karşı puanlar arıyorum. Teşekkürler.
Matt Cashatt

3
Şahsen ayrı bir DAL oluşturmak için hiçbir neden göremiyorum, çünkü EF / NHibernate kendi başlarına veri erişim katmanlarıdır. Marjan belirtildiği gibi, EF ile bunu düşünebilirsiniz eğer sen veritabanı satıcı değişimi görebilirsiniz onu (IMO) gereksiz kod olurdu böylece NHibernate size, bir satır kod (bellek içi test için bile SQLite sürücüsü) sürücülerini takas olabilir.
Patryk Ćwiek

3
İki DAL'ye gerek yok. Diğerlerinin de belirttiği gibi, BLL'nizi saklayın, ancak BLL'nizi satıcıya özgü yapılara kilitlemekten kaçının. Ben her zaman dize veya tamsayı seviyesine inmek görmek isterim. Daha sonra, web hizmetleri, seri port, telgraf bağlantısı, sadece şaka gibi çok ilkel bir kanaldaki tüm BLL / DAL kavşağını kolayca açığa çıkarabileceğimi biliyorum.
Andyz Smith

1
Yeniden Güncelleme: alay / stubbing / bir numara çünkü çok daha kolay busineslayer ait unittests yapabilir bu ekstra katman GetMyObjects(int myId)arasında taklit / stubbing / alay daha kolaydır GetObjects.Where(ob => op.accountId == myId).ToList().
k3b

Yanıtlar:


6

Aradığınız cevap bu mu emin değilim .. ama işte gidiyor.

Bunu ayrı tutmak / organize tutmak için yapıyoruz. Evet, EF / NHibernate veri erişimidir .. ancak genel bir veri havuzu kurulumu ile kullanımını kendi montajıyla sınırlandırıyoruz. Bu montaj aynı zamanda tüm NHibernate eşlemelerimizi, Oturum fabrikamızı, birden fazla veritabanını işlemek için kodumuzu içerir.

Hala "Veri Erişim Katmanı" olarak adlandırıyoruz, çünkü tüm montaj ORM'yi desteklemek için var.

Muhtemelen ana uygulamamızın 5 veritabanına atıfta bulunduğunu, kabaca 4-500 alan nesnesi / eşlemesi ve çeşitli şemaları olduğunu unutmayın. Bu kurulum bizim için mantıklı. Belki daha küçük bir uygulama için bu montaj atlamak istiyorum ama .. Ben organize kod için bir enayi ve muhtemelen yine de yaparım :)


2

EF ve DAL'ı bir Enterprise sisteminde ayrı bileşenler olarak görüyorum. Veri Erişim Katmanı, diğer hizmetlerin veri kalıcılığını ve yönetimini gerçekleştirmek için kullandığı bir soyutlamadır. Varlık Çerçeveleri genellikle sorgulama, güncelleme, silme ve ekleme etrafında güzel bir API oluşturur, ancak özünde yine de arka uç veri kaynağına doğrudan bağlantı gerektirir. Böylece her türlü yönlendirme veya güvenlik duvarı EF'in çalışmasını durduracak ve böylece bir EF uyumlulaştırma bileşeni oluşturmanızı gerektirecektir.

İşte DAL ve EF'in nereye oturduğunu gösteren üst düzey bir örnek:

-------------    -------                                    ----------------    ------
| Service A | -> | DAL | -> { LOCAL / LAN / WAN ACCESS } -> | DAL BACK-END | -> | EF |
-------------    -------                                    ----------------    ------

Deneyimime göre, daha iyi bir tasarım, iş mantığının veya hizmet uygulamalarının EF katmanına doğrudan erişmesine asla izin vermemektir. Bunun yerine, talepleri tel üzerinden göndermenizi veya yerel olarak gerçekleştirmenizi sağlayan tüm kalıcı verilerle çalışmak için bir soyutlama sağlamak.

Bu tasarım yine de bazı sızıntılı soyutlamalar getiriyor. Dolayısıyla duruma göre dikkate alınmalıdır.

Sorulacak bazı sorular:

  • Verilerinize erişen tüm bileşenler arka uç veri deposuna Bağlantı kurabilecek mi?
  • EF'niz, veri kümelerini farklı veri depolama türleri arasında birleştirmenize izin veriyor mu? Örneğin, belgeler için MongoDB ile bir SQL veritabanı kullanmak.

1

Günümüzde veri depolamasını değiştirip değiştirmeyeceğiniz sorusu eskisinden daha ilginç, çünkü soru sadece MS SQL veya Oracle SQL arasında değişip değişmeyeceğiniz değil, veri deponuz olarak çeşitli NoSQL veri depolama tekliflerini kullanabilir.

Bu tür bir değişikliğin ciddi bir olasılığı varsa, gelecekte depo isteklerinizi bir NoSQL veritabanına eşleyen yeni bir DAL ekleyebilmeniz için EF kodunuzu DAL'nizde izole tutmak değerli olabilir. Böyle bir değişiklik, elbette sürünen db ile ilgili varsayımlar nedeniyle BLL'nizin toptan yeniden yazılmasıyla sonuçlanabilir.

Benzer şekilde, bir DAL içindeki EF muhtemelen BLL kod birimi testleriniz için veri erişiminin taklit edilmesini daha kolay hale getirecektir.

Benim görüşüme göre EF (veya başka bir ORMS) veri erişim katmanı ihtiyacını ortadan kaldırmaz.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.