Zacznijmy od zdefiniowania do czego potrzebna nam jest tzw. warstwa biznesowa w systemie. Sama nazwa może nie wiele mówi i czasami okazuje się  nawet myląca.

Ogólnikowo  jest to rdzeń systemu. Stanowi zdecydowanie najważniejszy punkt każdej aplikacji. Warstwa biznesowa ( w skrócie BL – business layer) zawiera właściwą logikę aplikacji. Jeśli brzmi to zbyt abstrakcyjnie, przedstawmy to na przykładzie systemu sprzedaży (na którym będę często bazował). Co stanowi warstwę biznesową ( a więc logikę)  w systemie sprzedaży? Oczywiście składanie i walidowanie zamówień, śledzenie zmian przysyłki czy wybieranie produktów, które powinny być przecenione. Poniżej przedstawiam kilka według mnie kluczowych zadań BL:

1. Implementacja reguł biznesowych. Regułą biznesową może być np. “przeceń produkt jeśli jego sprzedaż w ostatnim kwartale zmalała n-razy”. W najprostszym przypadku w kodzie realizujemy to za pomocą instrukcji sterujących (np. if-else). W zaawansowanych przypadkach może okazać się, że potrzebny jest tzw. silnik reguł biznesowych czyli mechanizm umożliwiający dynamicznie definiowanie reguł – w przypadku modułu promocji jest to bardzo prawdopodobny scenariusz.
2. Walidacja danych. Sprawdzanie poprawności powinno odbywać się w każdej warstwie. W BL jednak jest to niezwykle ważne ponieważ błędne dane mogą spowodować nawet awarie systemu. Proste walidacje będą dotyczyły po prostu typu lub zakresu danych (np. czy podana wartość zawiera się w jakiś przedziale liczb). Z kolei skomplikowane reguły dotyczą wielu obiektów biznesowych jednocześnie oraz nie mają charakteru typowo technicznego( jak typ danych) a raczej biznesowy (wyznaczony przez ekspertów z danej dziedziny).
3. Monitoring oraz wykonywanie logów. O ile nie zdecydujemy się na dodatkową warstwę usług to wszelkie monitorowanie danych powinniśmy zawrzeć właśnie w BL. Temat jest dość szeroki i samo monitorowe też nie jest takie proste – istnieje dużo technologii wspomagających ten proces. Postaram się w przyszłości o tym napisać.
4. Buforowanie danych – sytuacja podobna, jeśli nie używamy warstwy usług to wszelkie buforowanie mające na celu przyśpieszyć obsługiwanie zgłoszeń należy zawrzeć w BL. Oczywiście buforowanie danych to również zadanie dla warstwy dostępu do danych a nawet warstwy prezentacji.
5. Obsługa błędów – w prostym przypadku użyjemy standardowego bloku try-catch. Jednak istotniejsze jest co zrobimy z tymi danymi. W niektórych systemach wszelkie krytyczne błędy powinny być wysyłane bezpośrednio do administratorów( np. za pomocą e-mail lub wiadomości SMS). Wszystko oczywiście zależy od postawionych wymagań oraz QoS ( quality of service).

Wiemy, już co warstwa powinna wykonywać. Kolejna pytanie brzmi, jak to ma wykonywać? Przede wszystkim kod BL powinien być maksymalnie elastyczny i abstrahować od źródła danych. Początkujący projektanci często popełniają następujące błędy:

1. Wywołują metody z warstwy prezentacji. Pamiętajmy, że żadna metoda w BL nie może w jakimkolwiek parametrze zawierać referencji do kodu związanego z warstwą prezentacji (w skrócie PL – presentation layer). To PL jest odpowiedzialne za przesłanie niezbędnych danych do BL a BL nie może odczytywać tych wartości samodzielnie z interfejsu użytkownika. Nawet dla najmniejszych aplikacji pamiętajcie aby umieścić BL w osobnym dll i pousuwać wszelkie referencję do warstwy prezentacji(choćby do biblioteki System.Windows.Controls).
2. Warstwa biznesowa nie formatuje danych. Jeśli BL zwraca cenę produktu to nie w formie uwzględniającej typ oraz zapis waluty – to jest już zadanie warstwy prezentacji. Podobnie należy sobie zdać sprawę, że BL nie jest odpowiedzialna za mechanizm globalizacji – wszelkie informacje muszą być przesyłane w sposób neutralny. Interpretacją oraz wizualizacją ich zajmuje się warstwa prezentacji.
3. Odczyt wartości z bazy danych bezpośrednio w BL. Wszelkie obliczenia w BL powinny abstrahować od typu i położenia źródła danych. Zatem jeśli potrzebujemy przetworzyć jakieś zamówienie powinniśmy operować na zwykłych klasach a nie pobierać dane bezpośrednio z bazy danych. W przypadku prostych wzorców projektowych takich jak skrypt transakcji należy skorzystać z jakiś bramek – ale to temat na następny post.

Dobre odizolowanie BL daje nam możliwość wyeksponowania kodu za pomocą np. WCF czy zwykłego web service. Należy podkreślić, że jest to właśnie ta warstwa, która odpowiada za realizację rzeczywistego problemu postawionego aplikacji. Pozostałe warstwy zależą głównie od wykorzystywanej technologii. Z kolei dobrze zaprojektowana BL powinna być maksymalnie niezależna. Dobry zwyczajem jest aby każda klasa w BL była typu POCO – ale to również temat na osobny post.