BLL, İş Mantığı Katmanıdır
DAL, Veri Erişim Katmanıdır
ASP.NET'ın üç kademeli mimarisi (DAL, BLL, UI)
Grafikler üç katmanlı bir yapıyı temsil eder. Web, USL katmanıdır
web –> bll –> dal
| | |
| V |
+–> model <—+
1. Üç kademeli mimari
1. Sunum katmanı (USL): Esas olarak WEB yöntemini temsil eder, ancak WINFORM modu olarak da ifade edilebilir. Mantık katmanı oldukça sağlam ve iyi kurulmuşsa, performans katmanı nasıl tanımlanır ve değiştirilirse değiştirilsin, mükemmel şekilde hizmet eder.
2. İş mantığı katmanı (BLL): esas olarak belirli sorunlar için, veri katmanının işleyişi ve veri işinin mantıksal işlemesi olarak da anlaşılabilir. Veri katmanı yapı taşları ise, mantık katmanı da yapı taşıdır.
3. Veri erişim katmanı (DAL): Esas olarak orijinal verinin işlem katmanıdır (veritabanı veya metin dosyası veya başka bir veri depolama biçimi şeklinde), yani veri işleyişi değildir, veritabanı değil, özellikle iş mantığı katmanı veya sunum katmanıdır
Veri hizmetlerinin sağlanması.
2. Özel ayrım
1. Sunum katmanı: esas olarak kullanıcının isteğini kabul eder ve veri döndürür, böylece istemci uygulamaya erişim sağlar.
2. İş mantığı katmanı: esas olarak veri katmanının işletilişinden sorumludur, yani bazı veri katmanı işlemlerinin birleşimi.
3. Veri erişim katmanı: Esas olarak veri katmanınızın mantıksal işleme içerip içermediğine bağlıdır; aslında işlevleri veri dosyasındaki çeşitli işlemleri tamamlar ve diğer işlemler için endişelenmezler.
3. Özet
Üç katmanlı yapı katı bir hiyerarşik yaklaşımdır; yani veri erişim katmanı (DAL) yalnızca iş mantığı katmanı (BLL) tarafından erişilebilir ve iş mantığı katmanı yalnızca sunum katmanı (USL) tarafından erişilebilir. Bazı üç katmanlı yapılar, Fabrika ve Model gibi diğer katmanlar da ekler; bunlar aslında bu üç katman temelinde bir uzantı ve uygulamadır.
Basit üç katmanlı bir program genellikle DAL BLL WEB Modeli'nin birkaç projesini içerir ve bunların karşılıklı referansları aşağıdaki gibidir
1) WEB referansları BLL, Model
2) BLL referansları DAL, Model
3) DAL referansları Modeli
4) Modelde atıf yok
Üç katmanlı mimari söz konusu olduğunda, herkes bunun performans katmanı (UI), iş mantığı katmanı (BLL) ve veri erişim katmanı (DAL) olduğunu bilir ve her katmanı alt bölmelerin birçok yolu vardır. Ama belirli kodun nasıl yazılacağı ve bu dosyaların hangi katmanda sayıldığı belirsiz. Aşağıda, üç katmanlı bir mimari projesini uygulamaya yönlendirecek basit bir örnek verilmiştir; bu örnekte yalnızca bir işlev vardır: kullanıcı yönetiminin basit bir yapısıdır.
Öncelikle, boş bir çözüm oluşturun ve aşağıdaki öğeleri ve dosyaları ekleyin
1. Bir ASP.NET Web Uygulaması projesi ekleyin, ona kullanıcı arayüzü adını verin ve yeni bir Web Form dosyası oluşturun User.aspx (User.aspx.cs dahil)
2. Bir ClassLibrary projesi ekleyin, adını BLL yapın ve yeni bir Class dosyası oluşturun UserBLL.cs
3. Bir ClassLibrary projesi ekleyin, adını DAL yapın ve yeni bir Class dosyası oluşturun UserDAL.cs. Bir SQLHelper referansı ekleyin. (Bu Microsoft'un veri erişim sınıfıdır ya da tüm veri erişim kodunu doğrudan yazabilirsiniz.) Genellikle yazdığım DataAccessHelper sınıfını kullanıyorum).
4. Bir ClassLibrary projesi ekleyin, adını Model yapın ve yeni bir Class tipi dosya oluşturun UserModel.cs
5. Bir ClassLibrary projesi ekleyin, ona IAL adını verin ve yeni bir Arayüz dosyası oluşturun IUserDAL.cs
6. Bir ClassLibrary projesi ekleyin ve adını ClassFactory
Sanırım bunun Petshop'un örneğinden farklı olmadığını ve daha basit olduğunu görüyorsunuzdur, çünkü ben de Petshop aracılığıyla üç katmanlı mimariyi öğreniyorum. Ancak bazı arkadaşlar bu projelerin seviyesi ve aralarındaki ilişki konusunda belirsiz olabilir, işte bunların tek tek açıklaması:
1. User.aspx ve User.aspx.cs
Her iki belge (ve dosyanın ait olduğu öğeler ve aşağıdakiler tekrarlanmayacaktır) sunum katmanının bir parçasıdır. User.aspx daha anlaşılması daha kolaydır çünkü bu bir ekran sayfasıdır. User.aspx.cs bazı insanlar bunun sayılması gerekmemesi, ancak iş mantığı katmanına dahil edilmesi gerektiğini düşünüyor. Katmanlama yapmazsanız, iş mantığını ve hatta veritabanını çalıştırmanızı User.aspx.cs bir sorun olmaz, ancak katmanlama yaparsanız bu yapılmamalıdır. Hiyerarşik bir yapıda, User.aspx.cs sadece görüntüyle ilgili içerikle ilgilenmeli ve başka hiçbir şey ele alınmamalıdır.
Örneğin, kullanıcıların bir liste şeklinde görüntülenme fonksiyonunu uygularsak, bilgi çıkarma işi BLL tarafından yapılır ve kullanıcı arayüzü (bu durumda User.aspx.cs) UserInfo almak için BLL'yi çağırdıktan sonra, listenin görüntülenmesini gerçekleştirmek için kod aracılığıyla User.aspx'nin veri kontrolüne bağlıdır. Bu süreçte User.aspx.cs arayüzde rol oynamıyor, sadece veri aktarmak için kullanılıyor ve kodlamanın çoğu böyle uygulandığı için, bazı insanlar User.aspx.cs arayüz olarak sayılmaması ve mantıksal işlem için BLL ile birleştirilmesi gerektiğini düşünüyor. Daha ileri bakıldığında, her kullanıcının önüne kullanıcının cinsiyetini canlı temsil etmek için bir simge eklemek için yeni bir gereklilik ortaya atıldı ve 18 yaş altındakiler için bu simge bir çocuk simgeyle temsil edildi. Bu gerekliliğin gerçekleşmesi User.aspx.cs dönüşüdür ve bu durumda User.aspx.cs gerçek bir kullanımı vardır.
2、NewBLL.cs
Aşağıdaki yöntemleri ekleyin:
public IList GetUsers(): Tüm kullanıcı bilgilerinin listesini döndürür
public UserInfo GetUser(int UserId): Belirtilen kullanıcının bilgilerini döndürer
public bool AddUser(UserInfo User): Kullanıcı bilgileri eklendi
public bool ChangeUser(UserInfo User): Kullanıcı bilgilerini güncelliyor
public void RemoveUser(int UserId): Kullanıcı bilgilerini kaldırır
Bu dosya, iş mantığı katmanına aiddir ve iş mantığıyla ilgili işlemleri yönetmeye ayrılmıştır. Birçok kişi bu katmanın tek kullanımının verileri performans katmanından veri katmanına iletmek olduğunu düşünebilir. Gerçekten çok sayıda böyle durum vardır, ancak bu sadece projenin nispeten basit olduğu veya proje ile işletme arasındaki ilişkinin yakından entegre olmadığı (örneğin şu anda popüler olan MIS) anlamına gelebilir, bu yüzden iş katmanının hiçbir ilgisi yoktur ve sadece ilete yönlendirme rolü oynar. Ancak bu, iş katmanının vazgeçilmez olduğu anlamına gelmez; proje büyüdükçe veya iş ilişkileri arttıkça, iş katmanı onun rolünü yansıtacaktır.
Buradaki en muhtemel hata, veri işlem kodunun iş mantığı katmanına ve veritabanını veri erişim katmanı olarak atanmasıdır.
Örneğin, bazı arkadaşlar BLL katmanının anlamsız olduğunu düşünüyor, ama DAL verilerini yükleyip işlem yapmadan arayüze iletiyorlar. Şu örneğe bir göz atın
BLL katmanı
SelectUser(UserInfo userInfo) kullanıcı adı veya e-posta adresine göre kullanıcı bilgilerini alır.
IsExist(UserInfo userInfo), belirtilen kullanıcı adı veya e-posta adresinin var olup olmadığını belirler.
O zaman DAL ayrıca BLL çağrısı için ilgili yöntemi de sağlar
SelectUser(UserInfo userInfo)
IsExist(UserInfo userInfo)
Bu şekilde, BLL sadece iletim rolünü oynar.
Ama eğer yaparsanız:
BLL. IsExist(Userinfo userinfo)
{
UerInfo kullanıcı = DAL. SelectUser(User);
return (userInfo.Id != null);
}
O zaman DAL IsExist() yöntemini uygulamaya gerek kalmaz ve BLL'de mantıksal işleme kodu vardır.
3、UserModel.cs
Varlık, bu şey, katmanlaştırmanın kolay olmadığını düşünebilirsiniz. Beni de dahil olmak üzere, bunu şöyle anladım: UI?àModel?àBLL?àModel?àDAL, bu yüzden Modelin katmanlar arasında veri iletimi için bir köprü görevi gördüğü düşünülüyor. Ama burada basit şeyleri değil, karmaşıklığı düşünmüyoruz.
Model nedir? Hiçbir şey değil! Üç katmanlı bir mimaride vazgeçilmez bir durumdur. Aslında nesne yönelimli programlamada en temel şey bu: sınıflar. Bir tablo bir sınıftır, bir haber aynı zamanda bir sınıftır, int, string, doublie vb. de sınıftır, sadece bir sınıftır.
Bu şekilde, modelin üç katmanlı mimarideki konumu, int ve string gibi değişkenlerin durumuyla aynıdır ve başka bir amacı yoktur; sadece veri depolama için kullanılır, ancak karmaşık verileri depolar. Bu nedenle, projenizdeki nesneler çok basitse, model olmadan birden fazla parametreyi doğrudan aktararak üç katmanlı bir mimari oluşturabilirsiniz.
Peki neden bir modele ihtiyacınız var ve faydaları nelerdir? Burada eklenmiş bir soru düşünürken akla gelen şeyler şunlardır:
Model, her katmanda parametrelerin geçişinde daha büyük bir rol oynayabilir mi?
Parametreleri katmanlar arasında aktarırken şunları yapabilirsiniz:
AddUser(userId,userName,userPassword,...,)
Ayrıca şöyle de olabilir:
AddUser(userInfo)
Bu iki yöntemden hangisi daha iyi? İlk bakışta, ikincisi olmalı ki çok daha iyi.
Normal değişken tipli katmanlar arasında parametreler ne zaman aktarılır (int, string, guid, double) ve Model ile hangileri aktarmalı? Aşağıdaki yöntemler:
SelectUser(int UserId)
SelectUserByName (dizi kullanıcı adı)
SelectUserByName (dizi kullanıcı adı, dize şifresi)
SelectUserByEmail(string email)
SelectUserByEmail (string email, string password)
Bu durum şöyle özetlenebilir:
SelectUser(userId)
SelectUser(user)
Burada kullanıcı modeli nesnesini kullanıcı adı, şifre ve e-posta kombinasyonlarının dört kombinasyonunu dahil etmek için kullanıyoruz. UserId de kullanıcı ile birleştirilebilir, ancak projedeki diğer BLL arayüzleri id parametreleriyle uygular, bu yüzden bu öğe de korunur.
userInfo geçti, peki bununla nasıl başa çıkılacak, bu sıraya göre olmalı, karar verilmesi gereken özel bir kod var.
Burada bu sırayla işleniyor
Önce hem kullanıcı adı hem şifreniz olup olmadığına bakın, sonra hem e-posta hem şifreniz var mı, sonra kullanıcı adınız olup olmadığına ve ardından e-posta adresiniz olup olmadığını kontrol edin. Sıralı olarak işleniyor.
Bu şekilde, gelecekte yeni bir içerik eklendiğinde, üyelik kartı (numara), arayüzü değiştirmeye gerek kalmaz, sadece DAL koduna numara desteği eklenir ve ardından üyelik kartı içeriğinin performans ve işleme bölümünü ön plana ekler.
4、UserDAL.cs
public IList SelectUsers(): Tüm kullanıcı bilgilerinin listesini döndürür
public UserInfo SelectUser(int UserId): Belirtilen kullanıcının güvenilir bilgilerini döndürür
public bool InsertUser(UserInfo User): Kullanıcı bilgileri eklendi
public bool UpdateUser(UserInfo User): Kullanıcı bilgilerini güncelliyor
public void DeleteUser(int UserId): Kullanıcı bilgilerini kaldırır
Birçok kişinin en çok anlayamadığı şey ise veri erişim katmanı, hangi kısmı veri erişim katmanı olarak kabul edilir? Bazı insanlar veritabanının veri erişim katmanı olduğunu düşünür, bu tanım konusunda net değildir; DAL veri erişim katmanıdır, veri depolama katmanı değil, yani veritabanı bu katman olamaz. SQLHelper'ın rolü, tekrarlayan kodlamayı azaltmak ve kodlama verimliliğini artırmaktır; bu yüzden verimliliğe alışkınsam veya veritabanı dışı bir veri kaynağı kullanmaya alışkınsam, istediğim zaman atılabilen bir parça olan SQLHelper'ı üç katmanlı mimarinin bir katmanı haline nasıl dönüştürebilirim?
Şöyle tanımlanabilir: veri kaynağı işlemleriyle ilgili kod, veri erişim katmanına ait olan veri erişim katmanına yerleştirilmelidir
5、IUserDAL
Veri erişim katmanı arayüzü, bu da vazgeçilmez bir şeydir, çünkü Petshop onu ve ClassFactory de beraberinde getirir, bu yüzden bazı projeler birden fazla veri kaynağını desteklemek zorunda kalmadıklarından bağımsız olarak bu iki şeyi yapar, bazıları ise ClassFactory yapmaz, sadece IDAL oluşturur ve sonra "IUserDAL iUserDal = yeni UserDAL(); Anlamını bilmiyorum. Bu tamamen bir kaplan, anti-dog değil.
Burada birçok kişi yanlış bir anlayışa sahip, yani böyle bir ilişki olduğuna inanıyor: BLL?àIDAL?àDAL, IDAL'ın BLL ile DAL arasında bir köprü görevi gördüğünü düşünür ve BLL ise DAL aracılığıyla DAL diyor. Ama gerçek şu ki, bunu böyle kodlasanız bile: "IUserDAL iUserDal = ClassFacotry.CreateUserDAL(); "iUserDal.SelectUsers()" çalıştırıldığında, aslında çalıştırılan IUserDAL örneği değil, UserDAL örneğidir, bu nedenle IDAL'in üçüncü katmandaki konumu DAL seviyesiyle ilişkilidir.
Yukarıdaki giriş sayesinde, üç katmanlı mimarinin hiyerarşisi temel olarak açıklanır. Aslında, üç katmanlı mimarinin standart olup olmadığını değerlendirmek için bir yolum var; yani, üç katmandan herhangi birinin tamamen değiştirilmesinin diğer iki katmanı etkilemeyeceği ve böyle bir yapı temelde üç katmanlı standardı karşılıyor (gerçi uygulanması daha zor ^_^ olsa da). Örneğin, projeyi B/S'den C/S'ye (veya tam tersi) değiştirirseniz, BLL ve DAL'ın değişmesi gerekmez, sadece kullanıcı arayüzü için; Ya da SQLServer'ı Oracle olarak değiştirin, sadece SQLServerDAL'ı OracleDAL ile değiştirin, başka işlem gerekmez vs. Başta makaleye özel bir kod eklemek istemiştim ama gerekli olduğunu düşünmüyorum, eğer siz gerekli bulursanız ekleyeceğim.
Özet: Bir katmanın size faydasız olduğu ya da uygulanması özellikle basit olduğu için gereksiz olduğunu düşünmeyin, onu terk edin ya da başka amaçlar için kullanın. Katmanlar gerçekleştirildiği sürece, katman sayısı ne olursa olsun, her katmanın net bir amacı ve işlev gerçekleştirmesi olmalı ve gerçek süreç tarafından etkilenmemeli, böylece aynı tür dosya farklı katmanlarda konumlandırılmalıdır. Aynı katmanın farklı işlevleri uygulamasına izin vermeyin. |
Yayınlandı 7.05.2015 10:53:35
|
|
|
