Gdzie umieścić logikę biznesową w projekcie MVC?

Stworzyłem prostą aplikację Java MVC, która dodaje rekordy do formularzy danych do bazy danych.

Moja aplikacja zbiera dane, sprawdza je i przechowuje. Wynika to z faktu, że dane pochodzą od różnych użytkowników online. dane mają głównie charakter liczbowy.

Teraz, gdy dane liczbowe są przechowywane w bazie danych (serwer SQL), chcę, aby moja aplikacja wykonywała obliczenia i wyświetlała wyniki. Użytkownik nie jest zainteresowany sposobem wykonywania obliczeń, dlatego należy je zamknąć. Użytkownik musi mieć możliwość przeglądania tylko prostych danych obliczeniowych (na przykład dane kolumny A minus dane kolumny B podzielone przez dane kolumny C). Wiem, jak pisać procedury składowane dla tego samego, ale chcę aplikację trójwarstwową.

Chcę danych, które umieszczam w bazie danych jako rekord, nad którymi pracuję, wykonując na nim obliczenia. Oryginalne dane powinny pozostać nienaruszone, podczas gdy nowe dane, po obliczeniach, muszą być przechowywane jako nowy rekord jednostki w bazie danych.

Gdzie mam napisać kod do tego obliczenia w tle? Ponieważ są to reguły i logika biznesowa, czy powinienem umieścić go w nowych plikach JavaBeans?

— BriskLabs Pakistan
źródło

możliwy duplikat pozostania OO i testowalności podczas pracy z bazą danych

— gnat,

Odpowiedzi:

Logiki biznesowej powinny być umieszczone w modelu , i powinniśmy dążyć do tłuszczu modeli i chude kontrolerów .

Na początek powinniśmy zacząć od logiki kontrolera. Na przykład: po aktualizacji kontroler powinien skierować kod do metody / usługi, która dostarcza zmiany do modelu.

W modelu możemy łatwo tworzyć klasy pomocnicze / serwisowe , w których można zweryfikować reguły biznesowe aplikacji lub obliczenia .

Podsumowanie koncepcyjne

Kontroler służy do logiki aplikacji. Logika charakterystyczna dla sposobu, w jaki aplikacja chce wchodzić w interakcje z „domeną wiedzy”, do której należy.
Model jest dla logiki, który jest niezależny od aplikacji . Ta logika powinna obowiązywać we wszystkich możliwych zastosowaniach „dziedziny wiedzy”, do której należy.
Dlatego logiczne jest umieszczenie wszystkich reguł biznesowych w modelu.

— EL Yusubov
źródło

ładna jasna i zwięzła odpowiedź ..

— hanzolo

@Yusubov, czy mógłbyś wyjaśnić mi różnicę między logiką aplikacji a logiką biznesową

— Mohamad

@Moh, w skrócie są to popularne słowa, które pomagają opisać poziomy technologii w aplikacji. Logika biznesowa to w zasadzie reguły systemu zgodne ze specyfikacjami funkcjonalnymi. Na przykład obiekt A typu B musi mieć przypisane C i D, ale nie E. Logika aplikacji jest raczej specyfikacją techniczną, na przykład za pomocą serwletów Java i OJB w celu zachowania w bazie danych Oracle.

— EL Yusubov,

Czy mógłbyś rozwinąć te słowa:

The most common mistakes are to implement application logic operations inside the controller or the view(presentation) layer.

[ php-html.net/tutorials/model-view-controller-in-php ]

— revo

Jeśli dobrze zrozumiałem, wspomniany artykuł odnosi się do „logiki aplikacji” jako „logiki biznesowej”. Zatem nic, co odnosi się do logiki biznesowej, nie powinno być umieszczane w kontrolerze ani w widoku.

— EL Yusubov

Jak zawsze zależy to od złożoności projektu.

W trywialnych aplikacjach, w których złożoność modelu domeny jest stosunkowo niewielka, można wprowadzić logikę do modeli i nazwać to dniem.

Jednak w przypadku nietrywialnych aplikacji ze złożonymi modelami i mnóstwem reguł biznesowych lepiej jest nieco oddzielić rzeczy.

Jeśli zastosujesz w modelu logikę biznesową, która obejmuje więcej niż jeden model, wprowadzasz ścisłe powiązanie między tymi modelami. W miarę rozwoju aplikacji, modele te stają się coraz bardziej znane god models, wiedząc zbyt wiele. A to szybko zmieni się w wielki bałagan, który trudno jest przetestować i utrzymać. W takim przypadku korzystne jest umieszczenie logiki w osobnej warstwie.

Decydując się na abstrakcję, zawsze bierz pod uwagę złożoność i cele aplikacji oraz unikaj nadmiernej inżynierii. W przypadku trywialnych / małych aplikacji wprowadzenie większej liczby warstw niż to konieczne zwiększa złożoność zamiast ją zmniejszać.

Robert Martin (wujek Bob) ma dobry post na blogu na ten temat: Czysta architektura.

— Hakan Deryal
źródło

pytanie dotyczyło MVC. logika biznesowa powinna zawsze znajdować się w modelu. Kontroler jest tylko adapterem.

— jgauffin

MVC jest jednym z najbardziej przeciążonych terminów w branży. Nie chcę wchodzić w dziwactwa tego terminu, ponieważ uzasadnia to książkę. Po prostu użycie MVC nie oznacza, że musisz umieścić każdą logikę w modelach.

— Hakan Deryal,

Z definicji Steve Burbeck (zespół Smalltalk)

The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate

. To jest definicja adaptera.

— jgauffin

Jeśli włożysz całą logikę do modelu, skończysz z tysiącami linii niemożliwego do utrzymania bałaganu. Byłem tam Nie jest grzechem mieć klasy użyteczności i warstwę usług.

— asthasr

Myślę, że jgauffin miał na myśli to, że pytanie jest specyficzne dla MVC. Jeśli zgadzamy się patrzeć na system z perspektywy MVC i tylko perspektywy MVC, to tak, cała logika biznesowa należy do „modelu”, ale „model” może obejmować wiele klas i warstw, w tym „klasy użytkowe” i „warstwa usługi”. Innymi słowy, nie twierdzilibyśmy, że warstwa serwisowa jest częścią kontrolera lub widoku, dlatego najlepszym rozwiązaniem jest model.

— DavidS

Umieszczenie logiki biznesowej w modelu może brzmieć najlepiej. Kontroler odbiera połączenie ze zdalnej aplikacji internetowej. Kontroler usługi internetowej MVC przejmuje wywołanie i przekierowuje wykonanie do metody w BL. Teraz Business Logic może być zawarty w „Modelu”, ale może być również umieszczony w innym folderze, powiedzmy „Business Logic” . Nie ma więc twardej i szybkiej reguły dotyczącej logiki biznesowej.

Korzystam z usługi internetowej zbudowanej na MVC 3.0, a logiką biznesową jest MODEL MVC .

— MontyPython
źródło

Zgadzam się. Otrzymujesz znacznie bardziej elastyczną aplikację, gdy Twój model jest po prostu strukturą danych, na którą działają inne klasy logiki biznesowej. Jako prosty przykład uważam, że jest to duża porażka podejścia ASP.NET do sprawdzania poprawności za pomocą atrybutów. Jeśli adnotuję właściwość FirstName osoby za pomocą atrybutu Wymagane, co się stanie, jeśli utworzę widok administratora, w którym imię nie powinno być wymagane? Warstwa logiki biznesowej powinna wykorzystać model i określić dla niego odpowiednie działania.

— xr280xr