Bye Bye MVC

Tworzenie aplikacji nie jest proste, a ostatnio zrobiło się jeszcze bardziej skomplikowane. Bo kiedyś to było łatwo: model i kontroler plus „głupi” widok jako prezentacja. Z tym „głupi” to tylko teoria, bo w praktyce każdy z nas widział różne kreatywne rozwiązania na temat tego co można do widoku wcisnąć. Więc, mieliśmy model i kontroler, rzut monetą i już wybrana funkcjonalność trafia albo tu, albo tam. Stąd też pytania: gdzie powinna być walidacja, w modelu czy kontrolerze. Ale to było kiedyś. W międzyczasie PHP dojrzało (o czym już wspominałem w innym artykule) i teraz, mając wsparcie języka, możemy tworzyć znacznie bardziej elastyczne rozwiązania. Wcześniej też można było się do nich przymierzać, ale wtedy też świadomość programistów PHP dotycząca poprawnej architektury była niewielka (konia z rzędu temu kto np. w 2008 roku wiedział co to DDD, realnie ogarniał SOLID, a nie tylko z nazwy). Teraz mamy jednak rok 2013 i dawno już nadszedł czas czegoś co na potrzeby niniejszego artykułu nazwałem roboczo MVC(B)L, czyli Model View Controller (Business) Logic. Do trójcy dodałem Logikę Biznesową.

I stała się światłość: MVC(B)L

Logika Biznesowa. Coś o czym przez lata zapominaliśmy. Pojawiały się kolejne frameworki, zachwycaliśmy się jak fajnie w nich tworzyć aplikacje, o ile wygodniej mamy, a nikt nie myślał o samej aplikacji. Każdy wchodził w schematy jakie nam frameworki narzuciły jak w masło, nawet nie pytał dlaczego, po co, ale jak to – skoro tak ktoś wymyślił, to tak ma być i ważne, że teraz jest jakby szybciej. Były mniej lub bardziej sztywne reguły to się do nich stosowaliśmy. Architektura aplikacji była efektem ubocznym stosowania frameworka, powstawała niejako przy okazji. W końcu jednak nadszedł czas aby to zmienić – dla mnie takim punktem granicznym jest wydanie Symfony2, bo to pierwszy duży gracz, który tak mocno postawił na architekturę, wzorce i dobre praktyki. Można S2 nie lubić, można mieć mu za złe różne rzeczy, ale trzeba oddać mu cześć i chwałę za to, że skierowało myślenie masy programistów na głębokie wody oceanu architektury aplikacji.

LB

Logika Biznesowa w MVC(B)L jest tym czymś co jest po prostu oczywiste, ale ze względu na ograniczenia jakie (domyślnie) narzucają nam frameworki było pomijane. Jest to nasza aplikacja. Kontroler to sterownik przepływu. Model to emanacja źródła danych, np. bazy. Widok powinien być „bezmyślny”, czystą prezentacją. Dodajmy helpery itp. rzeczy czyli małe klasy/biblioteki pomocnicze, niezwiązane z aplikacją, typowe narzędzia. A reszta to jest logika biznesowa. Gdzie powinna być walidacja? W logice biznesowej. Gdzie powinno być składane i sprawdzane zamówienie? W logice biznesowej. Gdzie powinna być obliczana rata kredytu? W logice biznesowej. To nie są tematy dla modelu i kontrolera. Kontroler może przyjąć żądanie i uruchomić proces składania zamówienia. Dalej powinien on przebiegać w osobnych klasach, osobnej warstwie – logice biznesowej. Jak wszystko przeszło poprawnie, to dane powinny być przekazane do modelu i zapisane do bazy. Najprościej model wyobrazić sobie jako repozytorium korzystające z encji. Encją jest zamówienie (ma swoje ID, a to jest wyróżnik encji), a repozytorium zajmuje się jego pobraniem, zapisaniem i innymi operacjami na encjach, zarówno pojedynczych, jak i np. przygotowywaniu danych do raportów. Cała logika tego co się dzieje przy zamówieniu, obliczanie podatków itp. jest nie w modelu, nie w kontrolerze, ale w warstwie logiki biznesowej – tam jest nasza aplikacja.

Nie ma lekko

MVC(B)L nie jest łatwe. To inny sposób myślenia. Polecam obejrzeć, przemyśleć i raz jeszcze się zastanowić się nad prezentacją Architecture the Lost Years by Robert Martin.

Nie jest to proste, bo to nie jest kolejny framework, nie ma gotowej dokumentacji wyjaśniającej nam jak powinna wyglądać architektura aplikacji którą tworzymy. Jedyny sposób aby do tego dojść to… myślenie. Nie boli, ale łatwe nie jest. Warto poczytać o DDD aby zobaczyć bardziej skomplikowaną wersję MVC(B)L. Załapać o co chodzi z repozytoriami, encjami i jak podchodzić do samej aplikacji. Tylko bez stresu, DDD to jest na prawdę ciężki temat, nie na każdą aplikację, warto jednak trochę o nim poczytać aby zrozumieć jak ważna jest logika biznesowa i „poczuć ducha” aplikacji 😉 Wiele z ogólnych koncepcji jakie tam są poruszone ułatwi nam zrozumienie tematu.

Konkluzja

Można zastanawiać się: po co to wszystko. Przecież mam framework, od lat tworzę w nim strony i jest OK. Jest, ale może być lepiej 😉 A tak serio, MVC(B)L ma kilka istotnych plusów:

  • łatwiej testować. Nie jesteśmy zależni od frameworka, bo kluczową logikę, którą powinniśmy testować mamy poza nim.
  • łatwiej ogarniać. Wszystko mamy w osobnych klasach, nie mieszają się ze sobą koncepcje frameworka, walidacji danych, składania zamówienia i zapisu do bazy. Bardziej świadomie tworzymy aplikację.
  • łatwiej przenosić. Możemy śmiało podmienić cały framework na inny bez ruszania ani jednej linijki kodu z logiki biznesowej. Czasami trzeba będzie dodać pewne proxy, które np. dane z nowego frameworka doprowadzi do standardu jaki miał stary framework i jakiego oczekuje logika biznesowa, ale samej istoty składania zamówienia nie będziemy zmieniali. Jest to plus trudny do przecenienia.
  • łatwiej wynosić. Możemy bardzo łatwo przenosić porcje logiki biznesowej między projektami/frameworkami.

Jeśli masz jakąś funkcjonalność, zastanawiasz się gdzie ją dać i zawsze wybierasz tylko między modelem i kontrolerem, to znak, że powinieneś na chwilę się zatrzymać, przestać myśleć schematami jakie proponują frameworki, a zacząć myśleć o aplikacji.

Bibliografia

Polecam prezentacje:
Clean Architecture and Design by Robert Martin
The A word, Discussion About Architecture

A jak ktoś woli czytać to np. darmowy ebook Domain Driven Design Quickly czy też liczne wpisy na temat DDD na internecie. Ponieważ to jest temat dotyczący architektury, więc nie ma większego znaczenia czy chodzi o PHP, czy Javę czy .NET – łatwo załapać analogię.

DDD było też poruszane w serii artykułów w ProgramistaMag, są one dostępne do pobrania (PDF) na stronie autora wraz z kompletnym przykładem DDD i CqRS (Java i .NET)

I jeszcze raz przypomnę: DDD jest ciężkie, nie chodzi o to aby od razu je całe zrozumieć, ale o to aby zacząć myśleć o logice biznesowej. Jak to załapiemy to wiele rzeczy stanie się oczywiste, a ograniczenia i schematy w jakie pakują nas frameworki będą dobrze widoczne.

Polecam też ten wpis: Clean Architecture by Robert Martin

Freelancer, programista php, wiecznie niezadowolony ze swojego kodu. Toleruje frontend, kocha backend, miłośnik integracji :)

Send this to a friend