Business Logic Layer (BLL) ne işe yarar?

Veritabanı uygulamaları için iyi uygulamaları okurken sık sık "iş mantığı katmanları" olarak adlandırılan savunucuları ile karşılaştım ve projemin bir tane kullanmanın en iyi olup olmadığına karar vermeye çalışıyorum (küçük bir kişisel proje). Benim sorunum, DLL'nin zaten işleyemeyeceği (sorguları yürütmek ve sonuçları nesnelere eşlemek) için BLL'nin yapabileceği bir şey düşünemediğimden kaynaklanıyor, bu yüzden BLL'm hiçbir şey yapmadan DAL'yi çağırıyor.

Belki de DAL'ın tam olarak ne yapması gerektiği konusunda yanılıyorum. Ancak, bir veritabanı yönetim uygulamasında bir BLL'den ne tür bir işlevsellik beklenmelidir?

Daha küçük uygulamalarım için, BLL'm genellikle DAL'a geçiş olarak başlar. Bununla iyiyim. İş kurallarını "keşfederken", BLL onları koyduğum yer. Ayrıca, testlerimi yazarken BLL'de çok fazla şey buluyorum. Kendi kişisel uygulamalarım için iş kurallarını oluşturuyorum ve BLL hala onları koyduğum yer. Benim için, BLL zamanla büyüyen bir şeydir. Bir proje üzerinde ne kadar uzun süre çalışsam, BLL o kadar büyük olur.

Küçük bir proje için BLL ve DAL'ı birleştirmeyi düşünebilir miyim? DAL teknolojilerini saç stillerini değiştirdiğim sıklıkta değiştirmem dışında, müşteri kodumu bundan izole edecek bir şeyim olmasını isterim.

BLL, kullanıcı alanının bir parçası değil, veritabanının bir parçası değil, iş alanının bir parçası olan şeyleri ele alır (genellikle). Örneğin, bir müşterinin yaşını, özel bir kıdemli indirime hak kazanıp kazanmadığını belirlemek için kullanma. DAL bunu yapmamalı, sadece müşteri verilerini almalı ve daha sonra BLL çalışmasını yaptıktan sonra indirim verileriyle birlikte saklamalıdır. DAL daha çok CRUD'a odaklanmalıdır. Küçük uygulamalarda, iki endişe çakışabilir.

Andrew

İş mantığı katmanları, etki alanı güdümlü geliştirme yaptığınızda ve etki alanının temel faaliyetlerine odaklandığınızda ortaya çıkan şeydir. Sunum katmanını (gui, web) ve altyapı katmanını (db, ağ bağlantısı vb.) Çıkarırsanız, bir banka hesabına para yatırmak gibi alan adınızın bir parçası olan temel aktivitelere sahip olursunuz. Artık iş katmanınızı modelleyip sunum ve altyapıdan izole ettiyseniz, web veya mobil cihazlar gibi diğer kullanımlara kolayca taşıyabilirsiniz. Gelişim hakkında düşünmenin temiz bir yolu ve gördüklerimden, ne yazık ki tüm bunları ciddiye almıyor.

Etki alanındaki odaklanma çabalarını haklı çıkartan iyi bir kitap olan Eric Evans - Domain Driven Design'a göz kulak olmanızı tavsiye ederim. Kuşkusuz, biraz kuru bir okuma yarı yarıya, ancak ivme kazanıyor ve geliştiricilerin bugünün sistemlerinde neyi yanlış yaptığına dair bazı güçlü inançlara sahip.

Belirli sayıda katman veya katmana sahip olmanız gerektiğini söyleyen hiçbir şey yok. Her şey projenizin karmaşıklığına bağlıdır. Nerd yemeği veya plak mağazası gibi birçok MVC örnek uygulamasına bir göz atın .. hepsi 2 katman kullanır, çünkü çok az işlem mantığı olan uygulamalar için mantıklı değildir.

Ancak, uygulamanız küçük olsa bile, normalde bir iş katmanı olacak üçüncü bir katman aracılığıyla veri katmanını sunum katmanından soyutlamaktan yararlanabilir. Bu, sunum katmanınızın her yerine tek bir yerde değişiklik yapmanıza olanak tanır.

ORM'nizi Linq'tan SQL'e Entity Framework'e (veya nhibernate) değiştirmeye karar verdiğinizi varsayalım. Sunum, sunum modeline sıkı sıkıya eğilimli olduğundan, işletme katmanında bunu sunum katmanınıza göre değiştirmek daha kolay olacaktır.

MVC'yi anlarsanız, yani .. Model View Controller, uygulama mimarinizi benzer terimlerle düşünebilirsiniz. Model veri katmanınıza benzer, Sunum katmanı Görünüm ve İş Katmanı Denetleyicidir.

Desolate Planet'in Etki Alanına Dayalı Tasarım hakkındaki cevabını tamamlamak :

Etki Alanına Dayalı Tasarım konseptleriyle çok uyumlu olan Soğan Mimarisini de inceleyin .

İş Mantığı "Katman" ın soğanın çekirdeği olduğuna ve her altyapı katmanının (veri erişim katmanı gibi) dış bağımlılıklarına dikkat edin. Bu, çok fazla test yapılmasına yardımcı olur, çünkü her harici altyapı bağımlılığını alay etmeli ve etki alanı mantığınızı tamamen test edebilmelisiniz.

Kanımca: İş Mantık Katmanı "saf kavramsal çözümün" yaşadığı yerdir. Gerisi sadece altyapı uygulama detaylarıdır.

Ancak, bazı uygulamaların bu tür bir mimariye ihtiyacı olmayabilir. Tüm uygulamalarınız veri kümesi CRUD işlemleri ise, 'saf kavramsal çözümünüz' aslında pratik olarak boş olabilir ve tek ihtiyacınız olan bir veritabanı düzenleme ön ucudur. Bu durumda, muhtemelen yalnızca DAL ve UI katmanlarına odaklanmaktan daha iyi olmalısınız.

Bu sorunun cevabı (IMHO): "DAL'ımı tamamen değiştirebilir ve herhangi bir iş mantığı kodumu yeniden yazmak zorunda kalmayabilir miyim?"

Sunum katmanınız gibi düşünün - farklı bir arayüz için GUI'yi değiştirmeyi düşünmek oldukça yaygın, kalın bir masaüstü GUI, bir iPhone uygulaması için değiştirilen bir web istemcisi için değiştirilir. BLL / DAL için böyle düşünmek o kadar yaygın değildir, çünkü belki de çok benzer bir şey (örneğin, MySQL ile değiştirilmiş bir SQLServer DB) dışında asla takas edilmezler, ancak DB'nizi dağıtılmış bir depolama birimine değiştirmeniz gerektiğini hayal ediyorsanız API kullanılarak erişilen hizmetlerde, katmanların nerede buluştuğu hakkında daha net bir fikir edinebilirsiniz.