Stworzyłem prostą aplikację Java MVC, która dodaje rekordy za pomocą formularzy danych do bazy danych.
Moja aplikacja zbiera dane, a także je weryfikuje i przechowuje. Dzieje się tak, ponieważ dane są pozyskiwane online od różnych użytkowników. 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 hermetyzować. Użytkownik musi mieć możliwość przeglądania tylko prostych danych obliczonych (na przykład dane z kolumny A minus dane z kolumny B podzielone przez dane z kolumny C). Wiem, jak pisać procedury składowane dla tego samego, ale potrzebuję aplikacji trójwarstwowej.
Chcę, aby dane, które umieściłem w bazie danych jako rekord, były przetwarzane przez wykonywanie na nich obliczeń. Oryginalne dane powinny pozostać nienaruszone, podczas gdy nowe dane, po obliczeniach, muszą zostać zapisane 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ć to w nowych plikach JavaBeans?
Komentarze
- możliwy duplikat Pozostawanie poza biurem i możliwość testowania podczas pracy z bazą danych
- Logika biznesowa to alias do faceta w twoim zespole / dziale, którego pytasz, jak zrobić / działać na modelu. Dlatego ' dlatego logika biznesowa może być przechowywana w oddzielnej klasie o nazwie Logika biznesowa. To samo dotyczy Presentation Logic, która jest synonimem projektanta, który odpowiada na pytania dotyczące formatowania lub wyświetlania komponentów interfejsu użytkownika. Może również istnieć logika programisty (pytania, które zadajesz i odpowiadasz samodzielnie lub swoim współpracownikom), która reprezentuje wiedzę o tym, jak tworzyć i łączyć ze sobą komponenty programu.
Odpowiedź
logika biznesowa powinna być umieszczona w model i powinniśmy dążyć do grubych modeli i chudych kontrolerów .
Na początek powinniśmy zacząć od logiki kontrolera. Na przykład: przy aktualizacji , kontroler powinien skierować kod do metody / usługi , która dostarcza twoje zmiany w modelu.
W modelu możemy łatwo utworzyć pomocnika / service klasy, w których aplikacja reguły biznesowe lub obliczenia mogą zostać zweryfikowane.
Koncepcyjne podsumowanie
-
Kontroler służy do obsługi logiki aplikacji. Logika specyficzna dla sposobu, w jaki aplikacja chce współdziałać z ” domeną wiedzy „, do której należy.
-
Model dotyczy logiki niezależnej od aplikacji . Ta logika powinna obowiązywać we wszystkich możliwych zastosowaniach ” domeny wiedzy „, do której należy.
-
Dlatego logiczne jest umieszczenie wszystkich reguł biznesowych w modelu.
Komentarze
- ładna, jasna i zwięzła odpowiedź.
- @Yusubov, czy mógłbyś mi wyjaśnić różnicę między logiką aplikacji a logiką biznesową
- @Moh, w skrócie są to przydatne słowa, które pomogą opisywać poziomy technologii w aplikacji. Logika biznesowa to w zasadzie zasady systemu zgodne ze specyfikacjami funkcjonalnymi. Na przykład Obiekt A typu B musiał mieć przypisane C i D, ale nie E. Logika aplikacji jest bardziej specyfikacją techniczną, jak używanie serwletów Java i OJB w celu zachowania w bazie danych Oracle.
- Czy mógłbyś opisz 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] - Jeśli dobrze zrozumiałem, wspomniany artykuł odnosi się do ' logiki aplikacji ' jako ' logika biznesowa '. Dlatego niczego, co odnosi się do logiki biznesowej, nie należy umieszczać w kontrolerze ani w widoku.
Odpowiedź
Jak zawsze, zależy to od złożoności projektu.
W prostych aplikacjach, w których złożoność modelu domeny jest stosunkowo niewielka, możesz umieścić logikę w modelach i nazwać to jednym dniem.
Jednak w przypadku nietrywialnych aplikacji ze złożonymi modelami i wieloma regułami biznesowymi lepiej jest trochę bardziej oddzielić rzeczy.
Jeśli umieścisz logikę biznesową, która obejmuje więcej niż jeden model modelu, wprowadzasz ścisłe powiązanie między tymi modelami.Wraz z rozwojem aplikacji modele te mają tendencję do przekształcania się w god models, wiedząc zbyt dużo. A to szybko zmieni się w wielki bałagan, który jest trudny do przetestowania i utrzymania. W takim przypadku warto umieścić logikę w osobnej warstwie.
Decydując o abstrakcji, zawsze bierz pod uwagę złożoność i cele aplikacji oraz unikaj nadmiernej inżynierii. W przypadku prostych / małych aplikacji wprowadzenie większej liczby warstw niż potrzeba zwiększa złożoność zamiast ją zmniejszać.
Robert Martin (wujek Bob) ma dobry post na blogu na ten temat: Czysta architektura.
Komentarze
- pytanie dotyczyło MVC. logika biznesowa powinna zawsze znajdować się w modelu. Kontroler to tylko adapter.
- MVC to jedno z najbardziej obciążonych terminów w branży. Nie ' nie chcę wchodzić w dziwactwa tego terminu, ponieważ gwarantuje on książkę. Po prostu użycie MVC nie ' nie oznacza, że musisz umieścić każdą logikę w modelach.
- Z definicji Stevea Burbecka (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 definicją adaptera. - Jeśli umieścisz całą logikę w modelu, skończysz z tysiącami linii nie do utrzymania. Byłem tam. ' nie jest grzechem posiadanie klas narzędzi i warstwy usług.
- Myślę, że jgauffin zmierza do tego, że pytanie jest specyficzne dla MVC. Jeśli zgodzimy się spojrzeć na system z perspektywy MVC i tylko z perspektywy MVC, to tak, cała logika biznesowa należy do modelu ” „, ale ” model ” może obejmować wiele klas i warstw, w tym ” klasy narzędzi ” i ” warstwa usług ” . Innymi słowy, nie ' nie powiedzielibyśmy, że warstwa usług jest częścią kontrolera lub widoku, dlatego najlepiej pasuje do modelu.
Odpowiedź
Umieszczenie logiki biznesowej w modelu może wydawać się najlepszym rozwiązaniem. Sterownik odbiera wywołanie ze zdalnej aplikacji internetowej. Kontroler w usłudze sieci Web MVC przyjmuje wywołanie i przekierowuje wykonanie do metody w BL. Teraz logikę biznesową można zawrzeć w „Modelu”, ale można ją również umieścić w innym folderze, np. „Logika biznesowa” . Nie ma więc sztywnej reguły określającej, gdzie będzie logika biznesowa.
Korzystałem z usługi internetowej opartej na MVC 3.0, a kontener logiki biznesowej to MVC MODEL .
Komentarze
- Zgadzam się. O wiele bardziej elastyczną aplikację uzyskuje się, gdy model jest po prostu strukturą danych, na którą działają inne klasy logiki biznesowej. Jako prosty przykład, myślę, że jest to poważna porażka podejścia ASP.NET ' do walidacji przy użyciu atrybutów. Jeśli dodam adnotację do właściwości FirstName osoby ' z atrybutem Wymagane, co się stanie, jeśli utworzę widok administratora, w którym imię nie powinno być wymagane? Warstwa logiki biznesowej powinna zużywać model i określać odpowiednie działania.