Po co umieszczać logikę biznesową w modelu? Co się stanie, gdy mam wiele rodzajów pamięci?

Zawsze myślałem, że logika biznesowa musi znajdować się w kontrolerze i że kontroler, ponieważ jest to „środkowa” część, pozostaje statyczna i że model / widok muszą być kapsułkowane za pomocą interfejsów. W ten sposób można zmienić logikę biznesową, nie wpływając na nic innego, zaprogramować wiele modeli (jeden dla każdej bazy danych / typu pamięci) i dziesiątki widoków (na przykład dla różnych platform).

Teraz czytam w tym pytaniu , że zawsze powinieneś umieszczać logikę biznesową w modelu i że kontroler jest głęboko związany z widokiem.

Dla mnie to naprawdę nie ma sensu i implikuje, że za każdym razem, gdy chcę mieć środki do obsługi innej bazy danych / rodzaju pamięci, muszę przepisać cały mój model, w tym logikę biznesową.

A jeśli chcę innego widoku, muszę przepisać zarówno widok, jak i kontroler.

Czy ktoś może wyjaśnić, dlaczego tak się dzieje, czy gdzieś się pomyliłem?

Odpowiedź ElYusubova przebija ją, logika domeny powinna przejść do modelu, a logika aplikacji do kontrolera.

Dwa wyjaśnienia:

• Pojęcie logiki biznesowej jest tutaj raczej bezużyteczne, ponieważ jest dwuznaczne. Logika biznesowa to ogólny termin na całą logikę, na której zależy przedsiębiorcom, oddzielający ją od zwykłych szczegółów technicznych, takich jak przechowywanie rzeczy w bazie danych lub renderowanie na ekranie. Zarówno logika domeny („prawidłowy adres e-mail wygląda jak ...”), jak i przepływy pracy / procesy biznesowe („gdy użytkownik się zarejestruje, poproś o swój adres e-mail”) są uważane za logikę biznesową, przy czym ta pierwsza wyraźnie należy do model, a ta ostatnia jest logiką aplikacji, która przechodzi do kontrolera.
• MVC to wzór do umieszczania rzeczy na ekranie i pozwalający użytkownikowi na interakcję z nim, w ogóle nie określa miejsca do przechowywania . Większość frameworków MVC to frameworki z pełnym stosem, które wykraczają poza zwykłe MVC i pomagają w przechowywaniu danych, a ponieważ dane, które powinny być przechowywane, zwykle znajdują się w modelu, ramy te zapewniają wygodne sposoby przechowywania modelu dane w bazie danych, ale nie ma to nic wspólnego z MVC. W idealnym przypadku modele powinny być niezależne od trwałości, a przejście na inny typ pamięci nie powinno w ogóle wpływać na kod modelu. W pełni rozwinięte architektury mają warstwę trwałości do obsługi tego.

Ty i duża część świata programowania wydaje się źle rozumieć, jakie są role części MVC. Krótko mówiąc, są to:

Model = logika domeny

Widok = logika wyjściowa

Kontroler = logika wejściowa

Oznacza to, że model odpowiada za całą logikę biznesową: wszystko, co jest związane z rysowaniem widżetów na ekranie, sterowaniem drukarką, wysyłaniem danych w formacie HTML, analizowaniem żądań HTTP itp. Itd., Nie należy do modelu.

Jednak wiele nowoczesnych tak zwanych frameworków „MVC” tak naprawdę wcale nie robi MVC lub źle opisuje swoje części. Dość często to, co nazywa się „modelem”, to warstwa trwałości modelu, podczas gdy logika biznesowa opiera się na czymś, co nazywają „kontrolerem”; rzeczywisty kontroler jest zwykle tylko centralnym punktem wejścia z tabelą routingu i odrobiną kodu w poszczególnych „kontrolerach”, aby wysłać otrzymane dane wejściowe do właściwych procesów biznesowych. To, co te ramy nazywają „widokiem”, to tak naprawdę wszystko: trochę logiki prezentacji (Widok), trochę obsługi danych wejściowych i sprawdzania poprawności (Kontroler) oraz trochę więcej logiki biznesowej (Model). Lwia część rzeczywistego widoku jest zwykle nazywana „szablonami”.

Możesz także przeczytać o architekturze wielopoziomowej; gdzie MVC jest rodzajem jednokierunkowym (przepływ to Kontroler -> Model -> Widok), wielopoziomowy jest rzeczą dwukierunkową (Prezentacja -> Logika -> Dane -> Logika -> Prezentacja) i całkiem sporo frameworki, które udają, że robią MVC, w rzeczywistości wykonują Trójwarstwowe, zmieniając etykiety Prezentacja do wyświetlenia, Logika do kontrolera i Dane do modelu.

Aby naprawdę wyodrębnić logikę biznesową i oddzielić ją od infrastruktury warstwy prezentacji, powinna być hermetyzowana przez usługi aplikacji. Architektura MVC jest sposobem na wdrożenie warstwy prezentacji i powinna pozostać w tym zakresie, delegując całą logikę biznesową na te usługi aplikacji. Pomyśl o modelach widoków jako o przejściówkach między widokiem a danymi, które muszą być wyświetlane i / lub czytane. Kontroler pośredniczy w interakcji między modelami widoków, widokami i usługami aplikacji obsługującymi logikę biznesową.

Usługi aplikacji implementują biznesowe przypadki użycia i są oddzielone od warstwy prezentacji, niezależnie od tego, czy jest to MVC, czy coś innego. Z kolei usługi aplikacji mogą obsługiwać skrypty transakcyjne lub projekty oparte na domenie .

W przypadku przechowywania usługa aplikacji może odwoływać się do repozytorium lub dowolnej abstrakcji mechanizmu trwałości. Różne implementacje mogą być wspierane poprzez abstrakcyjny dostęp do danych do interfejsu. Zazwyczaj te abstrakcje są nieszczelne i są tylko częściowo przenośne w różnych implementacjach i często jest to daremna próba uzyskania pełnej przenośności.

AKTUALIZACJA

Moja sugestia oparta jest na architekturze heksagonalnej . W architekturze heksagonalnej model domeny (logika biznesowa) stanowi rdzeń. Ten rdzeń jest zamknięty w usługach aplikacyjnych, które działają jak fasada . Usługi aplikacji to proste klasy, które mają metody odpowiadające przypadkom użycia w Twojej domenie. Aby uzyskać dogłębną dyskusję na temat usług aplikacji, zobacz Usługi w projektowaniu opartym na domenie . Przykładowy kod zawiera PurchaseOrderServiceusługę aplikacji dla domeny zakupów. (Należy pamiętać, że usługa aplikacji nie oznacza użycia projektowania opartego na domenie).

W architekturze heksagonalnej warstwa prezentacji MVC jest adapterem między modelem domeny (logiką biznesową) a GUI. Model domeny nie zna warstwy prezentacji, ale warstwa prezentacji zna model domeny.

To rozwiązanie ma z pewnością części ruchome niż rozwiązanie, które umieszcza logikę biznesową w kontrolerze, dlatego należy rozważyć wady i zalety. Sugeruję, że powodem tego jest to, że wolę oddzielić logikę biznesową od warstwy prezentacji w celu zwalczania złożoności. Staje się to coraz ważniejsze wraz z rozwojem aplikacji.

Zależy od tego, co rozumiesz przez logikę biznesową. Każda „logika”, która nadaje znaczenie treści modelu, powinna znajdować się w modelu. W połączonym pytaniu najwyżej głosowana odpowiedź wydaje się definiować „logikę biznesową” jako cokolwiek związanego z danymi; ma to sens z punktu widzenia tego, że dane firmy to jej sprawa!

Kiedyś widziałem przykład twórcy Railsów (tak myślę), który robił dokładnie o tym - nie wprowadzając do modelu „logiki biznesowej”. Jego przykładem była klasa kontrolera oraz metoda rejestracji aplikacji i logowania - dostarczone hasło w postaci zwykłego tekstu zostało zaszyfrowane przed włożeniem lub zapytaniem o model (bazę danych).

Nie mogę wymyślić lepszego przykładu czegoś, co nie jest logiką kontrolera i które należy bezpośrednio do modelu.

Model może być interfejsem do niezliczonych magazynów danych, łagodząc obawy związane z przenośnością. To tutaj można znaleźć zamieszanie w związku z tym, czy nie, interfejs modelu jest w rzeczywistości „kontrolerem”.

Ogólnie rzecz biorąc, kontroler łączy model i widok (które są mięsem i ziemniakami aplikacji). W rozwoju Cocoa może być uproszczone do tego stopnia, że ​​kontroler jest obsługiwany przez GUI XCode (obiekty kontrolera i powiązania).

Sekcja „Wzory projektowe” GoF na MVC, luźno cytowana:

Triada klas MVC służy do budowania interfejsów użytkownika w Smalltalk-80. Model jest obiektem aplikacji, widok jest prezentacją na ekranie, a kontroler określa sposób, w jaki interfejs użytkownika reaguje na dane wprowadzone przez użytkownika. MVC oddziela widoki i modele, ustanawiając między nimi protokół subskrypcji / powiadamiania. Poniższy schemat przedstawia model i trzy widoki. Dla uproszczenia pominęliśmy sterowniki.

W MVC chodzi o interfejsy użytkownika. Nacisk kładziony jest na model i widok - definiowanie i wyświetlanie danych. Zwróć uwagę na „protokół subskrybowania / powiadamiania” - tutaj przychodzi twój kontroler. Możesz zbudować wszystkie potrzebne widoki; tak długo, jak będą przestrzegać protokołu, nigdy nie będziesz musiał dotykać modelu ani kontrolera.

Jeśli chodzi konkretnie o tworzenie stron internetowych, wiele popularnych frameworków internetowych IMHO szybko i luźno posługuje się terminem MVC i jego definicjami komponentów.

Dlaczego nie wprowadzisz warstwy usług?

Wtedy twój kontroler będzie szczupły i bardziej czytelny, wtedy wszystkie funkcje kontrolera będą czystymi działaniami.

Możesz rozłożyć logikę biznesową tyle, ile potrzebujesz w warstwie usługi. Ponowne użycie kodu jest lepsze i nie ma wpływu na modele i repozytoria.