Logika biznesowa - co to jest?

pytanie zadane 17 lutego 2016 w Rozwój zawodowy, nauka, praca przez shimizu Obywatel (1,650 p.)

Aktualnie czytam o MVC i padło tam pojęcie, że model to logika biznesowa. Co tak na prawde kryje się za tą nazwą? Proszę o wyjaśnienie i przykłady (duuuużo)

To co czytam: http://michalorman.pl/blog/2010/03/model-widok-kontroler/

1 odpowiedź

odpowiedź 17 lutego 2016 przez event15 Szeryf (93,790 p.)
wybrane 18 lutego 2016 przez shimizu

Najlepsza

W przypadku 3GL (3 warstw) nie ma mowy o prawdziwej warstwie logiki biznesowej w modelu. W przypadku Modelu znaneog z MVC miesza się logikę biznesową z warstwą bazy danych i całej infrastruktury.

Do rzeczy. Chyba rozumiesz czym jest logika oraz czym jest biznes. Logikę możemy rozpatrywać tutaj jako ciąg przyczynowo-skutkowy - każda rzecz w Twoim systemie ma jakieś zasady które coś powodują. Biznes ma swoje reguły. Gdy łączymy logikę i biznes powstaje nam coś, co definiuje nam wymagania biznesowe odnoszące się do działania aplikacji.

W konteście programowania wymaganiem biznesowym nayzwamy coś, co daje kasę. Przykład: chcę by aplikacja miała guzik "Wczytaj grę". W tym przypadku wymaganiem biznesowym jest posiadanie wyłącznie guzika z takim napisem - nie funkcjonalność. Żeby spełnić to wymaganie - nie potrzeba wiele.

W rzeczywistości zadania do spełnienia kryteriów biznesowych (tak zwanej logiki) są dużo bardziej skomplikowane. Dajmy na to musimy zaprojektować system rezerwacji miejsc w kinie. Jednym z kryteriów będzie to, iż jedna osoba może zajmować tylko jedno miejsce. Ale jedna osoba może już zamówić (lub kupić) kilka miejsc dla kilku osób. Każda z tych osób może mieć inną zniżkę. Ktoś z nich może kupić miejsce vipowskie. Oczywiście to nie miejsce jest wyznacznikiem rezerwacji biletu lecz seans. Więc do danego seansu przywisywane są sale, w salach są miejsca. Jeśli zabraknie miejsc w sali, należy uruchomić nową salę i zaproponować seans w niej. Oczywiście jest to związane również z czasem o której ma być emitowany film.

Mogę tak cały czas rozprawiać - to wszystko wyżej wymienione to właśnie logika biznesowa. To wszystkie założenia dotyczące systemu nad którym się pracuje. Spełnienie każdego z tych założeń daje nam cegiełkę w postaci zaliczonego punktu biznesowego - im ich więcej tym lepiej.

Warstwa z modelem biznesowym jest sercem Twojej aplikacji. Niestety - w przypadku MVC nie masz dobrego rozgraniczenia logiki biznesowej od infrastruktury - a także często od frameworka z którego korzystasz - przez to aplikacja często staje się zależna od tych dwóch rzeczy. Jeśli nie są to duże projekty to nie ma większego znaczenia. Ale jeśli mają one się rozwiąć przez lata, to nie ma mowy o takiej architekturze, która jest już znana w latach 80 ubiegłego wieku.

W modelu znanym w MVC ustawiasz dosłownie wszystkie ify, wszystkie funkcje sprawdzające poprawność danych, tworzysz klasy każdego ważnego obiektu w Twoim systemie. Pozwalasz by obiekty te były przesyłane do bazy danych i odbierane z nich. Ja tego nie pochwalam, no ale trzeba znać ten model.

komentarz 17 lutego 2016 przez event15 Szeryf (93,790 p.)

niezbyt trafnej nazwy, oraz encji wymyślonych dla celów platformy Java EE.

Swoją drogą chłopak nie wie, że słowo encja jest starsza od javy...

Normalnie klasy mapujące tabele w bazie i wykonujące logikę to powinny być te same klasy

Eh, poszukaj innego tuta MVC bo tu zgasił moją chęć do dalszego czytania zupełnie. Dobrze Ci radzę, bo nauczysz się głupot od niego.

komentarz 17 lutego 2016 przez shimizu Obywatel (1,650 p.)

Polecisz coś? Najlepiej po polsku bo mało czasu mam. Po angielsku też może być

komentarz 18 lutego 2016 przez event15 Szeryf (93,790 p.)

To warto przeczytać:

http://symfony.com/doc/current/best_practices/business-logic.html

http://symfony.com/doc/current/book/from_flat_php_to_symfony2.html

Jeśli chodzi o krótki wstępniak.

Jeśli chcesz dowiedzieć się jak dokładnie rozmieć model w którym istnieje sama logika biznesowa - Eric Evans i jego Domain-Driven Design. Z tym, że musisz mieć solidny fundamet wiedzy z zakresu obiektówki bo to książka już tylko dla takich osób i zakłada że wzorce projektowe, czy metodyki pracy są czytelnikowi znane. Niezależnie od tego co pisze autor we wstępie. Jednak jest to chyba najpełniej opisany model dziedzinowy, w którym rozróżnia się 4 warstwy niemalże niezależne od siebie.

W takim podejściu dzieli się projekt aplikacji na kilka programów/projektów - które są nieco mniejsze.

Prezentacja - sam wygląd aplikacji. W przypadku stron internetowych jest to HTML+CSS + JavaScript, który dzięki swoim możliwością komunikuje się z serwerem API (kolejnej warstwy). Nie ma tam ani jednej linijki backendu, jest tylko operowanie na danych otrzymanych z serwera i wysyłanych do niego.
Aplikacji - najczęściej jakiś framework, który umożliwia nam stworzenie api restowego (albo jakieś serwisy). Za jego sprawą warstwa prezentacji może wydawać polecenia do warstw niższych. API jest jakby takim kontrolerem. Może być rozwijany zupełnie oddzielnie od innych warstw (pod warunkiem, że niższe zostały już zrobione ;) ). Tu również znalazły miejsce tak zwane domain events czy coś takiego jak CQRS o którym na razie nie musisz wiedzieć bo z nim często wiąże się coś takiego jak Read Model i Write Model.
Model dziedziny (logika biznesowa) - serce aplikacji. Tu właśnie wszystkie encje i niezmienniki mają swoje miejsce. Ta część kodu powinna być przetestowana najbardziej - testy jednostkowe i testy specyfikacji. Wszystko, co istnieje tutaj ma swoje znaczenie i w odpowiedni sposób komunikuje się ze sobą. Jeśli stosuje się CQRS wcześniej wspomniany, to powstają dwa różne modele do reprezentacji tego samego. Dzięki takiemu zastosowaniu możemy korzystać z kilku baz danych na jednej aplikacji - jedna baza służąca do odczytu dancych - która na przykład jest zabójczo szybka - i druga, która zajmuje się tylko zapisem danych. Obie reprezentują ten sam obiekt modelu, jednak są inaczej zaprogramowane - w celu zwiększenia wydajności.
Infrastruktura - tu i wyłącznie tu jest miejsce na zapytnia kierowane do bazy danych. Tych baz danych może być wiele.

Trzeba pamiętać, że takie podejście jednak wymaga sporej wiedzy i skilla w programowaniu. Wtedy dopiero poznaje się na czym polega prawdziwe programowanie i jak wyglądają poważne problemy wielkich firm. W pewnym momencie ludzie są zafascynowani rozwiązywaniem matematycznych problemów za pomocą programów. Jednak spoje i inne strony o ćwiczenia programowania nie dają dużo w takim przypadku. Tu już trzeba mieć obszerną wiedzę z zakresu projektowania modelu obiektowego, z samego programowania obiektowego i wzorców projektowych i architektonicznych. Do tego trzeba rozumieć jak działa biznes a nie algorytm, który można w kilka minut wyszukać w necie. Stosując 4GL człowiek jest zachęcany do stosowania masy wzorców jednocześnie reguły tworzenia oprogramowania w ten sposób są ściśle określone i to wymusza tworzenie dobrych jakościowo programów.

---------------

Wracając do MVC musisz wiedzieć, ze nie jest to wzorzec projektowy, tylko architektoniczny. Zwykle składa się z kilku wzorców. W przypadku stron internetowych jest to jakiś routing, jakiś singleton czy register oparty na singletonie, fasada no i nierzadko observer.

Jeśli będziesz rozumieć zasadę działania tych wzorców i będziesz wiedzieć jak z nich korzystać - a także nie będą Ci sprawiać żadnego problemu w korzystaniu to będziesz potrafić zrobić samodzielnie mini framework w stylu MVC. MVC charakteryzuje się niestety tymi singletonami, które sprawiają, iż obiekty są globalne w programie - co jednak w czysto obiektowym konteście nie powinno mieć miejsca. Jednak istnieje coś takiego jak Dependency Injection. Ale idź z duchem przeszłości i naucz się najpierw tych wzorców o których wspomniałem.

Jeśli już będziesz znać przynajmniej te wzorce - zainteresuj się testami jednostkowymi w swoim języku.

Tu opisałem bardzo ciekawą formę ćwiczeń w ich stosowaniu:

http://zapachy-kodu.pl/testowanie/tdd/php-kata-czynniki-pierwsze-prime-factors/2016/01/

A tu opisałem dlaczego dane globalne są nie do końca ok:

http://zapachy-kodu.pl/cleancode/dane-globalne-enkapsulacja-i-czarne-pudelka/2016/01/

Jeśli będziesz szukać informacji o dobrych technikach programowania to czytaj książki: Robert C. Martin (wszystkie wręcz bo każda z nich traktuje na bardzo ważne tematy - jednak nie traktuj go jak boga nowej religii), Kent Beck i jego praca o TDD, Roy Osherove, który również pisze o TDD tylko w mega przystępny sposób.

Dodatkowo, wyhacz gdzieś Kod Doskonały spod microsoftowego skrzydła, gdyż jest to jedna z najlepiej opisujących ogół programowania książek wydana do tej pory.

Jeśli chcesz poznać dogłębnie (wręcz aż za bardzo) tajniki programowania obiektowego to szukaj na allegro czy innych aukcjach Bertrand Meyer Programowanie zorientowane obiektowo. Jego praca zawierająca 1500 stron jest najpełniej opisanym dziełem dotyczącym programowania obiektowego i każdego dosłownie aspektu z tym związanego. Jest to książka sprzed czasów Roberta C. Martina i część rzeczy (jak SOLID) jest właśnie w tej rozprawie zapoczątkowana, tylko po innymi nazwami - tak dla tych, którzy myślą że Robert. C. Martin sam to wymyślił ;).

Jeśli wolisz coś mniejszego i równie przystępnego, to: Myślenie obiektowe w programowaniu pana Matt'a Weisfelda. Traktuje dosłownie o tym samym co poprzednia książka - tylko ma 300 stron zamiast 1500.

Jeśli 4 warstwy Cię zaciekawiły i nie boisz się wyzwań to zasięgnij po Eric Evans - Domain-Driven Design. Jednak to jest cegła dla wytrwałych. Początek się czyta bez entuzjazmu i leci się tak do połowy książki, która zaczyna wciągać coraz bardziej - później wracasz do początku bo przespałeś go praktycznie w całości i czytasz na nowo środkowe rozdziały, aż w końcu dochodzisz do końcówki która znów wydaje się nudniejsza ale po niej jest jeszcze coś co wymusza na tobie powtórzenie książki. Generalnie jedna z najtrudniejszych książek do czytania jakie miałem w ręku ale też jeśli chodzi o profesjonalizm i wiedzę zawartą w niej to druga na liście - po Bertrandzie Meyerze.

Oczywiście jeśli chodzi o wzorce projektowe - banda czworga i Ich "wzorce projektowe". Absolutnie trzeba mieć tę książkę. Jeśli chce się ruszyć po poważniejsze dzieła. Dla mnie bardzo pochłaniające i czytałem od dechy do dechy 4 razy no i na wyrywki później. Niektórzy mówią iż język jest niezrozumiały i że ciężko się czyta - no cóż, kto co lubi.

Teraz jeśli chodzi o refaktoryzacje - bo w końcu poznasz to pojęcie. Są dwie książki które dobrze opisują to zagadnienie. Jedna z nich to REFAKTORYZACJA taka niebieska autorstwa 4 czy 5 osób. No i Refaktoryzacja do wzorców projektowych. Druga książka jest zainspirowana poprzednią i wzorcami projektowymi bandy czworga. Więc jest tu mocna zależność pozycji od siebie.

No i kolejny hardkor, z którego sporadycznie korzystam - Architektura systemów zarządzania przedsiębiorstwem - wzorce projektowe. Jest to również jeden z kanonów, jednak tu są poruszane tematy bardzo dużych systemów i opisuje bardzo dokładnie każdy wzorzec - w tym przypadku spotkamy się z wzorcami głównie bazodanowymi i modelów.

Na razie tyle ode mnie :)

komentarz 18 lutego 2016 przez maly Nałogowiec (37,190 p.)

MVC charakteryzuje się niestety tymi singletonami

Nie czytałem całości ale w oko ukuło mnie i tu pytanie, uwaga pytam: Czo?

komentarz 18 lutego 2016 przez event15 Szeryf (93,790 p.)

Czemu niby Cię to "ukuło"?

komentarz 18 lutego 2016 przez adrian17 Ekspert (344,860 p.)

Eh, poszukaj innego tuta MVC bo tu zgasił moją chęć do dalszego czytania zupełnie.

W Django, który jest MVC-podobny, nie widzi się niczego złego w umieszczaniu części logiki w modelu.

komentarz 18 lutego 2016 przez maly Nałogowiec (37,190 p.)

Wzorzec architektoniczny nie jest uzależniony od wzorca projektowego więc nie może się nim charakteryzować.

komentarz 18 lutego 2016 przez event15 Szeryf (93,790 p.)

@maly, zrób mi MVC bez fasady czy observera i powiedz mi, czy nie jest uzależniony.

@adrian17, dziś przeczytałem to zdanie jeszcze raz i okazuje się że nieco inaczej je przeczytałem wczoraj. Więc racja - logika w modelu spoko. Raczej nigdzie indziej - tylko jestem przeciwnikiem zapytań bazodanowych w modelu jako takim.

@mały, jako iż jestem phpowcem to biorę pod uwagę kwestie, które trzeba wykonać poza samym mvc który bez tych rzeczy raczej nie podziała.

komentarz 18 lutego 2016 przez maly Nałogowiec (37,190 p.)

Skoro nie zchrakteryzowałeś samej koncepcji MVC tylko jeden ze sposób jej implementacji, to dlaczego napisałeś "MVC charakteryzuje się..."?

komentarz 18 lutego 2016 przez event15 Szeryf (93,790 p.)

@mały, po pierwsze nie o to pytał autor tematu, po drugie znakomita większość sposobów implementacji MVC wykorzystuje singletony chociażby do kreacji obiektów. Czasem Registry, który również wykorzystuje singletona.

Nie wiem jak dokładnie wygląda to w C#, Javie czy Pythonie jednak uważam, że bez użycia Registry jest ciężko. Oczywiście jest masa różnych implementacji tegoż wzorca, tak samo jak masa implementacji wzorca Observer, jak i Fasady.

Z czystym sumieniem mówię iż tradycyjny MVC opiera się na singletonach - późniejsze implementacje również nierzadko wykorzystują singletony.

Książki opisujące MVC (http://helion.pl/ksiazki/wzorzec-mvc-w-php-dla-profesjonalistow-chris-pitt,wzomvc.htm ) mówią o tym, iż bez singletona będzie ciężko, tak samo PoEAA wspomina o różnych implementacjach Registry jednak jej najpopularniejsza i najczęściej wykorzystywana forma ma postać z singletonem w środku.

Zajrzę do jakiejkolwiek książki to opisuje tworzenie frameworków MVC wyłącznie w sposób z singletonem.

Inna sprawa, że mvc nie jest wystarczający w wielu przypadkach większych aplikacji.