GUI, BLL, DAL Bir Projede Organizasyon

Uygulama katmanları hakkında okuyorum ve bu tasarımı bir sonraki projemde kullanmak istiyorum (c #, .Net). Bazı sorular:

1. Katmanların ayrılması ad alanları üzerinden mi yapılıyor? Project.BLL.Ne olursa olsun, Project.DAL.Whatever

2. Katmanlara, sonra bileşenlere (Project.BLL.Component1) veya bileşenlere, ardından katmanlara (Project.Component1.BLL) ayırmak daha uygun mu?

3. Benim DAL'ım için, bu katman farklı sınıflar kullanılarak daha mı düzenleniyor? Tüm veritabanı çağrıları tek bir sınıfa konursa, kuruluş yoktur. Bunları farklı sınıflara veya ad alanlarına bölmek daha iyi olur mu?

4. DAL sınıfları genellikle statik midir? Her seferinde yöntemlerinden birini çağırmadan önce bir DAL nesnesini somutlaştırmak hantal görünüyor.

Bu katmanlarla işleri doğru şekilde yapmaya yönelik diğer ipuçları takdir edilecektir.

1. Evet. Ve ayrıca meclisler.
2. Önce katmanlar, sonra bileşenlerle ayırırdım.
3. Evet. Bu farklı yaklaşımlar vardır, ama bir IDatabaseService (veritabanı çağrıldığı çeşitli görgü soyutlama) olurdu - bu neredeyse ExecuteScalar / ExecuteNonQuery / ExecuteReader doğrudan bir eşleme olabilir ve sonra çeşitli veri erişim sınıfları olabilir veri türüne göre bölümleme. Örneğin, Kullanıcı nesnelerini oluşturan / değiştiren / değiştiren basit CRUD yöntemlerine sahip bir UserDataAccess sınıfınız olabilir. Başka bir yaklaşım, CRUD'nin yerleşik olarak oluşturulmuş bir User nesnesine sahip olmak olacaktır.

4. Hayır Yani yapar çok zor birim testine. Her veri erişim sınıfının yapıcısına (IDatabaseService gibi) bağımlılıkları aktarmak için bağımlılık enjeksiyonu kullanmalısınız . Daha sonra veri erişim nesnelerini aşağıdaki gibi iş nesnelerine geçirirsiniz:

   BusinessObject businessObject = yeni BusinessObject (yeni DataAccessObject (yeni DatabaseService ())); businessObject.PerformOperation ();

Her iş nesnesinin birden fazla veri erişim nesnesine ihtiyacı olabilir. GUI kodunuz ayrıca bir veya daha fazla iş nesnesi kullanır. Bazı iş nesneleri herhangi bir veri erişim nesnesine ihtiyaç duymayabilir ancak hiçbir zaman doğrudan IDatabaseService kullanmamalıdır.

Soru 1 ve 2 için Matthew'un cevapları ile devam edin.

Masaüstü uygulamalarının DAL'ını yapılandırmanın en iyi yolunu bulmaya çalışmak için çok zaman harcadım. Ve en iyi yol gerçekten uygulamanın ihtiyaçlarına bağlıdır. Uygulamalarımdan birinde, her bir veritabanı tablosu için bir DA sınıfına sahip olmak için yola çıktım, bu da kendisini merkezi (yani singleton) bir DataProvider sınıfıyla kaydetti ve CRUD'yi işledi. Daha sonra her DA sınıfı, tüm tablo verilerini RAM'de önbelleğe alıp almayacağını (performans!) Ve / veya diğer bilgisayarlarda çalışan diğer istemcilerde otomatik istemci güncellemelerini tetikleme yeteneğine sahip olup olmayacağına karar verebilir (çok kullanıcılı olduğunu düşünün) eşzamanlılık). Bu, yeni DAL sınıfları eklemeyi çok kolaylaştırır, çünkü tek yapmaları gereken kayıt arayüzüne uymaktır.

Her DAL'ın bu tür bir işlevselliğe ihtiyacı yoktur, ancak yeni dersler eklemeye başladığımda yaklaşımın kendisinin (yani tektonlu veri sağlayıcısı ve statik kayıtlı basit DAL sınıfları) hayatımı çok daha kolay hale getirdiğini öğrendim.

Çok basit bir uygulama olmadıkça kesinlikle CRUD'yi daha üst sınıflara inşa etmenizi tavsiye etmem. DAL, veri deposunun bir soyutlamasıdır. Veri depolama alanınızı gelecekte bir noktada değiştirmeye karar verirseniz (yalnızca MS SQL yerine MySQL kullanmak olsa bile), bunun için çok minnettar olacaksınız. Artı: BLL nesneleri iş mantığı ilişkileri tarafından yapılandırılmalıdır. DAL nesneleri, temsil ettikleri saklama kaplarının türlerine göre yapılandırılır. Farklılıklar dramatik olabilir.

Do DEĞİL DAL sınıfları statik olun. Kodlama hızında kazandığınız şey, test edilebilirlik ve esneklikte birçok kez kaybedersiniz.