Logika biznesowa w MVC

Fist of all:
Wierzę, że mieszasz wzorzec MVC i zasady projektowania oparte na N-warstwach.

Korzystanie z podejścia MVC nie oznacza, że nie powinieneś tworzyć warstw aplikacji.
Może to pomóc, jeśli zobaczysz MVC bardziej jak rozszerzenie warstwy prezentacji.

Jeśli umieścisz kod bez prezentacji wewnątrz wzorca MVC, wkrótce możesz skończyć w skomplikowanym projekcie.
Dlatego sugerowałbym, aby umieścić swoją logikę biznesową w oddzielnym biznesie warstwa.

Wystarczy spojrzeć na to: Artykuł w Wikipedii o architekturze wielowarstwowej

Pisze:

Obecnie MVC i podobny model-widok-prezenter (MVP) są oddzieleniem wzorców projektowych, które odnoszą się wyłącznie do warstwy prezentacji większego systemu.

W każdym razie ... gdy mówimy o enterprise web application wywołania z interfejsu użytkownika do warstwy logiki biznesowej powinny być umieszczone wewnątrz (prezentacja) kontroler.

Dzieje się tak dlatego, że kontroler faktycznie obsługuje połączenia do określonego zasobu, zapytuje dane, wykonując połączenia do logiki biznesowej i łączy dane (model) z odpowiednim widokiem.

Mud powiedział ci, że zasady biznesu wchodzą w model.
To również prawda, ale pomieszał model (prezentacyjny) ("M" W MVC) i model warstwy danych w projekcie aplikacji opartych na warstwach.
Dlatego ważne jest umieszczenie firmy związanej z bazą danych reguły w modelu (warstwie danych) twojej aplikacji.
Nie należy jednak umieszczać ich w modelu warstwy prezentacji o strukturze MVC, ponieważ dotyczy to tylko określonego interfejsu użytkownika.

Ta technika jest niezależna od wheathera, który używa projektu opartego na domenie lub podejścia opartego na skrypcie transakcji.

Pozwól mi to sobie wyobrazić.:

Warstwa prezentacji: Model-widok-kontroler

Business layer: Domain logic-Application logika

Data layer: Data repozytoria-Data access layer

Model, który widzisz powyżej oznacza, że masz aplikację, która używa MVC, DDD i niezależnej od bazy danych warstwy danych.
Jest to powszechne podejście do projektowania większej aplikacji internetowej przedsiębiorstwa.

Ale można go również zmniejszyć, aby użyć prostej warstwy biznesowej innej niż DDD (warstwy biznesowej bez logiki domeny) i prostej warstwy danych, która zapisuje bezpośrednio do określonej bazy danych.
Mógłbyś nawet upuść całą warstwę danych i uzyskaj dostęp do bazy danych bezpośrednio z warstwy biznesowej, chociaż nie polecam.

To jest sztuczka...Mam nadzieję, że to pomoże...

[uwaga:] Należy również pamiętać o tym, że obecnie w aplikacji jest więcej niż jeden "model". Zwykle każda warstwa aplikacji ma swój własny model. Model warstwy prezentacji jest specyficzny dla widoku, ale często niezależny od używanych kontrolek. Warstwa biznesowa może mieć również model, nazywany "modelem domeny". Zazwyczaj dzieje się tak, gdy zdecydujesz się na podejście oparte na domenie. Ten "model domeny" zawiera zarówno dane, jak i logikę biznesową (główną logikę programu) i jest zwykle niezależny od warstwy prezentacji. Warstwa prezentacji zwykle wywołuje warstwę biznesową na określonym "wydarzeniu" (naciśnięty przycisk itp.) do odczytu lub zapisu danych do warstwy danych. Warstwa danych może również mieć własny model, który jest zazwyczaj związany z bazą danych. Często zawiera zestaw klas encji oraz Dao (Data-access-objects).

Pytanie brzmi: jak to pasuje do koncepcji MVC?

Odpowiedz - > nie ma!
Tak jakby, ale nie do końca.
dzieje się tak dlatego, że MVC jest podejściem, które zostało opracowane w późnych latach 70-tych dla języka programowania Smalltalk-80. W tym czasie GUI i komputery osobiste były dość rzadkie i world wide web nie został nawet wymyślony! Większość dzisiejszych języków programowania i IDE zostały opracowane w latach 90. W tym czasie Komputery i interfejsy użytkownika były zupełnie inne niż w latach 70.]} Powinieneś o tym pamiętać, gdy mówisz o MVC.
Martin Fowler napisał bardzo dobry artykuł o MVC, MVP i dzisiejszym GUI.

Termin logika biznesowa nie jest moim zdaniem dokładną definicją. Evans mówi w swojej książce Domain Driven Design o dwóch typach logiki biznesowej:]}

• logika domeny.
• logika aplikacji.

Ta separacja jest moim zdaniem dużo jaśniejsza. A wraz z uświadomieniem sobie, że istnieją różne rodzaje reguł biznesowych, przychodzi również uświadomienie sobie, że nie wszystkie muszą iść w tym samym miejscu.

Logika domeny to logika odpowiadająca rzeczywistej domena. Jeśli więc tworzysz aplikację księgową, reguły domeny będą regułami dotyczącymi kont, wpisów, podatków itp. W zwinnym narzędziu do planowania oprogramowania reguły będą takie, jak obliczanie dat wydań na podstawie prędkości i punktów historii w zaległościach itp.

Dla obu tych typów aplikacji Import/Eksport CSV może być istotny, ale reguły importu/eksportu CSV nie mają nic wspólnego z rzeczywistą domeną. Tego rodzaju logika jest zastosowanie logika.

Logika domeny z pewnością wchodzi w warstwę modelu. Model odpowiadałby również warstwie domeny w DDD.

Logika aplikacji nie musi jednak być umieszczona w warstwie modelu. Które mogą być umieszczone bezpośrednio w kontrolerach lub można utworzyć oddzielną warstwę aplikacji hostującą te reguły. To, co jest najbardziej logiczne w tym przypadku, zależy od rzeczywistej aplikacji.

A1: logika biznesowa przechodzi do Model części MVC. Rola Model Jest zawierać dane i logiki biznesowej. Controller z drugiej strony jest odpowiedzialny za odbieranie danych wejściowych użytkownika i decydowanie, co robić.

A2: A Business Rule jest częścią Business Logic. Mają has a związek. Business Logic ma Business Rules.

Spójrz na Wikipedia entry for MVC. Przejdź do przeglądu, gdzie wspomina przepływ MVC wzór.

Zobacz też Wikipedia entry for Business Logic. Mówi się, że Business Logic jest składa się z Business Rules i Workflow.

To jest odpowiedź na pytanie, ale dam swój "jeden cent":

Zasady biznesowe należą do modelu. "Model" zawsze składa się z (logicznie lub fizycznie oddzielonych):

• model prezentacji - Zestaw klas, który dobrze nadaje się do użycia w widoku (jest dostosowany do konkretnego interfejsu użytkownika/prezentacji),
• model domeny - niezależna od interfejsu część modelu i
• Repozytorium - część "modelu" świadoma pamięci masowej.

Reguły biznesowe żyją w modelu domeny, są eksponowane w formie dostosowanej do modelu "prezentacji" i czasami są powielane (lub też egzekwowane) w "warstwie danych".

Jak wskazało kilka odpowiedzi, uważam, że istnieje jakieś nieporozumienie dotyczące architektury multi tier vs MVC.

Architektura wielowarstwowa polega na rozbiciu aplikacji na warstwy / warstwy (np. prezentacja, logika biznesowa, dostęp do danych)

MVC to styl architektoniczny warstwy prezentacji aplikacji. W przypadku aplikacji nietrywialnych logika biznesowa/reguły biznesowe/dostęp do danych nie powinny być umieszczane bezpośrednio w modelach, widokach lub kontrolerach. Na byłoby to umieszczenie logiki biznesowej w warstwie prezentacji, a tym samym zmniejszenie ponownego użycia i konserwacji kodu.

Model jest bardzo rozsądnym wyborem do umieszczenia logiki biznesowej, ale lepszym / bardziej utrzymywalnym podejściem jest oddzielenie warstwy prezentacji od warstwy logiki biznesowej i utworzenie warstwy logiki biznesowej i po prostu wywołanie warstwy logiki biznesowej z modeli, gdy jest to potrzebne. Warstwa logiki biznesowej z kolei wywoła dostęp do danych warstwa.

Chciałbym zwrócić uwagę, że często zdarza się znaleźć kod łączący logikę biznesową i dostęp do danych w jednym ze składników MVC, zwłaszcza jeśli aplikacja nie została zaprojektowana przy użyciu wielu warstw. Jednak w większości aplikacji korporacyjnych często można znaleźć architektury wielowarstwowe z architekturą MVC w warstwie prezentacji.

Nie ma sensu umieszczać warstwy biznesowej w modelu dla projektu MVC.

Powiedz, że twój szef zdecyduje się zmienić warstwę prezentacji na coś innego, będziesz miał przerąbane! Warstwa biznesowa powinna być oddzielnym zespołem. Model zawiera dane pochodzące z warstwy biznesowej, która jest przekazywana do widoku w celu wyświetlenia. Następnie na przykład w post model wiąże się z klasą Person, która znajduje się w warstwie biznesowej i nazywa PersonBusiness.SavePerson (p); gdzie p jest Klasa osoby. Oto, co robię (brakuje klasy BusinessError, ale też poszedłbym do BusinessLayer):

Q1:

Logikę biznesową można rozpatrywać w dwóch kategoriach:

1. Logika domeny, taka jak kontrolki na adresie e-mail (unikalność, ograniczenia itp.), uzyskanie ceny produktu do faktury, lub obliczenie całkowitej ceny produktu na podstawie jego przedmiotów produktu.

2. Bardziej szerokie i skomplikowane przepływy pracy, które nazywane są procesami biznesowymi, jak kontrolowanie procesu rejestracji dla ucznia (który zwykle składa się z kilku kroków i wymaga różnych kontroli i ma bardziej skomplikowane ograniczenia).

pierwsza Kategoria przechodzi do modelu, a druga należy do kontrolera. Dzieje się tak dlatego, że przypadki w drugiej kategorii są szeroko pojętą logiką aplikacji i umieszczenie ich w modelu może mieszać abstrakcję modelu (na przykład, nie jest jasne, czy musimy umieścić te decyzje w jednej lub drugiej klasie modelu, ponieważ są one związane z obu!).

Zobacz to odpowiedź dla konkretnego rozróżnienia między modelem a kontrolerem, ten link dla bardzo dokładnych definicji, a także ten link dla ładnego przykładu Androida.

Chodzi o to, że notki wymienione powyżej przez "Mud" i "Frank" mogą być prawdziwe, podobnie jak "Pete" (logika biznesowa może być umieszczona w modelu lub kontrolerze, w zależności od rodzaju logiki biznesowej).

Na koniec zauważ, że MVC różni się w zależności od kontekstu. Na przykład w aplikacjach na Androida, sugerowane są pewne alternatywne definicje, które różnią się od internetowych (patrz na przykład ten post).

Q2:

Logika biznesowa jest bardziej ogólna i (jak wspomniano powyżej" decyklon") mamy między nimi następującą relację:

Zasady biznesu ⊂ logika biznesu

Model = kod operacji bazy danych CRUD.

Controller = odpowiada na działania użytkownika i przekazuje żądania użytkownika o pobranie danych lub usunięcie/aktualizację do modelu, z zastrzeżeniem reguł biznesowych specyficznych dla organizacji. Te reguły biznesowe mogą być zaimplementowane w klasach pomocniczych lub, jeśli nie są zbyt złożone, bezpośrednio w akcjach kontrolera. Kontroler na koniec prosi widok o aktualizację, aby dać użytkownikowi informację zwrotną w postaci nowego wyświetlacza lub wiadomość typu "Aktualizacja, Dzięki", itp.,

View = UI, który jest generowany na podstawie zapytania dotyczącego modelu.

Nie ma twardych i szybkich zasad dotyczących tego, gdzie powinny pójść zasady biznesowe. W niektórych konstrukcjach przechodzą w model, podczas gdy w innych są dołączane do kontrolera. Ale myślę, że lepiej trzymać je przy kontrolerze. Niech model martwi się tylko o łączność z bazą danych.