Veri Erişim Katmanındaki İş Nesneleri

Bu yüzden TDD aracılığıyla bir veri erişim katmanı oluşturuyorum ve endişe duyuyorum. Yanlış yola başlamak istemem, bu yüzden sizden düşüncelerimin temiz bir mimariye uygun olup olmadığını görmenizi isteyeceğim.

Veri Erişim Katmanımdaki (kısaca DAL) yöntemler oldukça basittir. Veritabanındaki saklı yordamlarla uyumludur (işleri temiz tutmak için onu çağırmanın başka bir yolu yoktur) ve yordamlarla aynı parametreleri içerirler. Daha sonra veritabanına bağlanırlar ve sorgu sonucunu döndürürler. İşte bir örnek:

public int DeleteRecord(int recordId)
{
    recordId.RequireThat("recordId").NotZeroOrLess();

    List<SqlParameter> parameters = new List<SqlParameter>();
    parameters.Add(new SqlParameter { ParameterName = "@RecordId", SqlDbType = SqlDbType.Int, Direction = ParameterDirection.Input, Value = recordId});

    return this.ExecuteNonQuery("DeleteRecord", parameters.ToArray());
}

Sonuç kümesi ile anlamlı bir şey yapmıyorum çünkü bu yöntem için mükemmel çalışır. Sadece komutun çalıştığından emin olmak istiyorum, bu yüzden sadece etkilenen satırlar olan sorgu olmayan sonucu döndüreceğim ve bu sayıyı kullanarak mantığı doğrulayabilirim.

Ancak, başka bir DAL yönteminde, bir kayıt yüklemek istiyorum diyelim. Benim yük prosedürü yürütme olacak selectstabloların bir grup ve bir dönülmesine karşı DataSetama İş oluşturmalısınız benim DAL kullanarak yöntemi içinde Nesneleri olup olmadığı mücadele ediyorum DataSet, ya benim İş Nesneleri eğer kendilerini sadece olmalı Load()alır yöntemi DataSetve daha sonra temelde kendini doldurur.

Bunu DAL üzerinden yapmak İş Nesnelerinde daha az mantıkla sonuçlanır (bu sadece belirli bir mantık olsa da, yine de mantıktır), ancak DAL'ı biraz kalabalıklaştıracak ve gerçekten yapmaması gereken bir şey yapıyormuş gibi hissettirecek ' yapmıyorum.

Siz ne düşünüyorsunuz?

DAL'niz veri nesnelerinizi döndürmelidir

İdeal olarak DAL'niz, uygulama kodunuzun bir veri nesnesi istemek veya mevcut veri nesnelerini değiştirmek için kullanabileceği bir "kara kutu" nesnesi olmalıdır. Bazen Repository, her zaman gerekli olmamakla birlikte , DAL ve the denilen uygulama kodu arasına , iki katmanı daha da ayıran başka bir katman vardır .

Ayrıca, genellikle iş nesnelerinizin kendilerini oluşturabilmesini istemezsiniz. Bu, birinin kitaplığınızı kullanabileceği güvenlik deliklerine neden olabilir .Load(someId)ve onu çağırarak nesnenizin yeni bir örneğini oluşturabilir ve tamamen ayrı olması gereken iki katmanı birleştirir.

Ben de bir sağlama önermiyoruz .Load(DataSet ds)veri seti tanım değişirse, o veri kümesini kullanan ve bunları değiştirmek veri nesneleri avlamak gerekecek çünkü yöntemi. Tüm veri erişim kodunuzu tek bir yerde tutmak daha kolaydır, bu nedenle veri erişim sorgusunu değiştirirseniz, yalnızca DAL katmanınızı değiştirmeniz gerekir.

Metodum, LINQ-To-SQL ve Entity Framework'ten önce bile, uygulamanın farklı katmanları arasındaki iletişim için "yazılı bir sözleşme" sağlayan bir arayüz ve soyut sınıf kütüphanesine sahip olmaktı. Buna bazen ontoloji , çalışma alanı için bir tanım denir . Katmanlar arasında geçen her şey bu 'sözleşmeyi' kullandı.

Ham veri kümesi nesnelerini veri katmanından iş katmanına geçirme fikrinden hoşlanmıyorum. Bu sonucu, özellikle eski veri kaynaklarını entegre ederken bir dizi sorunla karşılaştım. Ayrıca, bir projeye gelen yeni insanların verilerin nereden geldiğini anlamasını zorlaştırabilir. Son olarak, iş katmanınızın veriyi doğrudan DB'den yönetme işinde olmasını gerektirir ve bu da yolda komplikasyonlara yol açabilir.

Sahip olduğunuz örnek kod LINQ öncesi koduna benziyor. DAL nesnelerimin içinde kullandığım ortak bir DB işlev sınıfı vardı. DAL sınıfları verileri okuyacak ve 'sözleşme' nesnelerine sığdıracaktır. Skalar sonuçlar, silme örneğiniz gibi, genellikle bir boole değeri döndürür.

DAL'niz bir Veri Kümesi döndürmelidir. Döndürülen Veri Kümesinin iş nesnesi olması gerekir, beklenen verilere sahip olup olmadığını kontrol etmek dışında ona yapmanız gereken hiçbir şey olmamalıdır. Bununla daha fazlasını yapmanız gerekiyorsa, tek bir saklı yordamda çok fazla şey yapmaya çalışıyorsunuz veya saklı yordamda verileri düzgün bir şekilde döndürmüyorsunuz.

İş nesnelerinizin kendilerini bir sonuç kümesinden doldurmak için bir kurucuya sahip olmasını öneririm. Bu, DAL'niz ve iş katmanınız arasındaki bağlantıyı kaldırır. İkisini tamamen izole etmek istiyorsanız, sonuç kümenizden basit bir sütun adı => değer çiftleri haritası oluşturun ve bunu yapıcıya iletin.