Jakie zastosowanie ma warstwa logiki biznesowej (BLL)?

Czytając o dobrych praktykach dotyczących aplikacji bazodanowych, często spotykam się z zwolennikami tak zwanych „warstw logiki biznesowej” i staram się zdecydować, czy najlepiej, aby mój projekt z nich korzystał (jest to mały projekt osobisty). Mój problem polega na tym, że nie mogę wymyślić niczego, co by BLL mogło zrobić, czego DAL nie może już obsłużyć (wykonywanie zapytań i mapowanie wyników na obiekty), więc moja BLL po prostu wywołuje DAL bez robienia czegokolwiek.

Może mylę się co do tego, co powinien robić DAL. Ale niezależnie od tego, jakiego rodzaju funkcjonalności należy oczekiwać od BLL w aplikacji do zarządzania bazą danych?

W przypadku moich mniejszych aplikacji moja BLL zwykle zaczyna się jako przejście do DAL. Nic mi nie jest. Kiedy „odkrywam” reguły biznesowe, BLL jest tam, gdzie je umieszczam. W trakcie pisania testów znajduję też wiele rzeczy potrzebnych w BLL. W przypadku moich osobistych aplikacji tworzę reguły biznesowe, a BLL wciąż tam je umieszczam. Dla mnie BLL jest czymś, co rośnie z czasem. Im dłużej pracuję nad projektem, tym większy jest jego BLL.

Czy rozważałbym połączenie BLL i DAL dla małego projektu? Mogę, z wyjątkiem faktu, że zmieniam technologie DAL tak często, jak zmieniam fryzury, i lubię mieć coś, co odizoluje od tego kod mojego klienta.

BLL obsługuje elementy, które są częścią domeny biznesowej, a nie częścią bazy danych, a nie częścią interfejsu użytkownika (zwykle). Na przykład przy użyciu wieku klienta w celu ustalenia, czy kwalifikuje się on do specjalnej zniżki dla seniorów. DAL nie powinien tego robić, powinien po prostu pobierać dane klienta, a następnie przechowywać je z danymi rabatu po zakończeniu pracy BLL. DAL powinien bardziej koncentrować się na CRUD. W małych aplikacjach te dwie kwestie mogą się pokrywać.

Andrzej,

Warstwy logiki biznesowej są tym, co kończy się, gdy tworzysz programowanie oparte na domenie i skupiasz się na podstawowych działaniach domeny. Jeśli usuniesz warstwę prezentacji (GUI, sieć) i warstwę infrastruktury (db, łączność sieciowa itp.), Masz podstawowe działania, które są częścią twojej domeny, takie jak wpłata pieniędzy na konto bankowe. Teraz, jeśli modelowałeś swoją warstwę biznesową i odizolowałeś ją od prezentacji i infrastruktury, możesz łatwo przenieść ją na inne zastosowania, takie jak Internet lub urządzenia mobilne. To czysty sposób myślenia o rozwoju i z tego, co widziałem, nie bierze się tego wszystkiego tak poważnie.

Polecam zdobyć Eric Evans - Domain Driven Design, która jest dobrą książką, która uzasadnia skupienie wysiłków programistycznych na domenie. Wprawdzie jest to trochę sucha lektura w połowie, ale nabiera tempa i ma silne przekonanie co do tego, co programiści robią źle z dzisiejszymi systemami.

Nic nie mówi, że musisz mieć określoną liczbę poziomów lub warstw. Wszystko zależy od złożoności twojego projektu. Spójrz na wiele przykładowych aplikacji MVC, takich jak nerd dinner lub sklep muzyczny. Wszystkie używają 2 warstw, ponieważ w przypadku aplikacji, które mają bardzo małą logikę przetwarzania, nie ma to po prostu sensu.

Jednak nawet jeśli Twoja aplikacja jest mała, może odnieść korzyść z abstrakcji warstwy danych od warstwy prezentacji za pośrednictwem trzeciej warstwy, która normalnie byłaby warstwą biznesową. Umożliwia to wprowadzanie zmian w jednym miejscu, a nie w całej warstwie prezentacji.

Załóżmy, że zdecydujesz się zmienić ORM z Linq na SQL na Entity Framework (lub nhibernate). Prawdopodobnie łatwiej będzie to zmienić w warstwie biznesowej niż w warstwie prezentacji, ponieważ prezentacja ściśle łączy się z modelem prezentacji.

Jeśli rozumiesz MVC, tj. Model View Controller, możesz pomyśleć o architekturze aplikacji w podobny sposób. Model jest podobny do warstwy danych, warstwa prezentacji jest widokiem, a warstwa biznesowa kontrolerem.

Uzupełnienie odpowiedzi Desolate Planet na temat projektowania opartego na domenach:

Zobacz także architekturę cebuli , która jest bardzo zgodna z koncepcjami projektowania opartego na domenie.

Zauważ, że „warstwa” logiki biznesowej jest rdzeniem cebuli, a każda warstwa infrastruktury (np. Warstwa dostępu do danych) jest jej zewnętrznymi zależnościami. Pomaga to w wielu testach, ponieważ powinieneś być w stanie wyśmiewać każdą zależność od zewnętrznej infrastruktury i w pełni przetestować logikę domeny.

Moim zdaniem: warstwa logiki biznesowej to miejsce, w którym żyje „czyste rozwiązanie koncepcyjne”. Reszta to tylko szczegóły implementacji infrastruktury.

Jednak niektóre aplikacje mogą nie wymagać tego rodzaju architektury. Jeśli wszystkie Twoje aplikacje to operacje CRUD w zbiorze danych, twoje „czysto koncepcyjne rozwiązanie” może być praktycznie puste i wszystko, czego potrzebujesz, to interfejs do edycji bazy danych. W takim przypadku lepiej powinieneś skupić się tylko na warstwach DAL i UI.

Odpowiedź na to pytanie brzmi (IMHO): „Czy mogę całkowicie zastąpić mój DAL i nie muszę przepisywać żadnego kodu logiki biznesowej”?

Pomyśl o tym jak o warstwie prezentacji - dość często myślisz o zmianie GUI na inny, gruby graficzny GUI na pulpicie zostaje zamieniony na klienta WWW, który zamienia się na aplikację na iPhone'a. Nie jest tak często tak myśleć w przypadku BLL / DAL, ponieważ tak naprawdę nigdy nie są zamieniane, z wyjątkiem może czegoś bardzo podobnego (np. SQLServer DB zamienionego na MySQL), ale jeśli uważasz, że musiałeś zmienić DB na pamięć rozproszoną usługi, do której dostęp uzyskano za pomocą interfejsu API, można uzyskać jaśniejsze wyobrażenie o tym, gdzie spotykają się warstwy.