Derik Whitaker opublikował artykuł kilka dni temu, w którym dotarł do punktu, którego ciekawiło mnie od jakiegoś czasu: czy logika biznesowa powinna istnieć w kontrolerach?
Jak dotąd wszystkie prezentacje ASP.NET MVC, które widziałem, umieszczały dostęp do repozytorium i logikę biznesową w kontrolerze. Niektórzy nawet wrzucają tam również walidację. Powoduje to dość duże, nadęte kontrolery. Czy to naprawdę sposób na użycie frameworka MVC? Wygląda na to, że skończy się to na dużej ilości zduplikowanego kodu i logiki rozproszonej po różnych kontrolerach.
asp.net-mvc
design-patterns
controller
business-logic
Kevin Pang
źródło
źródło
Odpowiedzi:
Logika biznesowa naprawdę powinna być w modelu. Powinieneś dążyć do grubych modelek, chudych kontrolerów.
Na przykład zamiast mieć:
Wolałbym mieć:
Zakłada się, że podatek jest obliczany przez usługę zewnętrzną i wymaga, aby model wiedział o interfejsach do usług zewnętrznych.
To sprawi, że twój kontroler będzie wyglądał mniej więcej tak:
Czy jakoś tak.
źródło
Podoba mi się diagram przedstawiony przez Microsoft Patterns & Practices . I wierzę w przysłowie „Obraz jest wart tysiąca słów”.
źródło
To fascynujące pytanie.
Myślę, że to interesujące, że duża liczba przykładowych aplikacji MVC w rzeczywistości nie jest zgodna z paradygmatem MVC w sensie prawdziwego umieszczenia „logiki biznesowej” w modelu. Martin Fowler zwrócił uwagę, że MVC nie jest wzorem w sensie Gang Of Four. Raczej jest to paradygmat, że programista musi dodać wzorce do jeżeli są one tworząc coś poza app zabawek.
Krótka odpowiedź brzmi więc, że „logika biznesowa” rzeczywiście nie powinna istnieć w kontrolerze, ponieważ kontroler ma dodatkową funkcję zajmowania się widokiem i interakcjami użytkownika, a my chcemy tworzyć obiekty tylko w jednym celu.
Dłuższą odpowiedzią jest to, że przed przeniesieniem logiki z kontrolera do modelu należy przemyśleć projekt warstwy modelu. Być może poradzisz sobie z całą logiką aplikacji za pomocą REST, w takim przypadku projekt modelu powinien być dość przejrzysty. Jeśli nie, powinieneś wiedzieć, jakie podejście zamierzasz zastosować, aby zapobiec rozdęciu modelu.
źródło
Możesz sprawdzić ten niesamowity samouczek Stephena Walther, który pokazuje Validating with a Service Layer .
źródło
Logika biznesowa nie powinna być zawarta w kontrolerach. Kontrolery powinny być tak chude, jak to tylko możliwe, najlepiej podążać za wzorcem:
Dodatkowo kontrolery mogą zawierać logikę aplikacji.
Więc gdzie umieścić logikę biznesową? W modelu.
Co to jest model? To dobre pytanie. Zobacz artykuł o wzorcach i praktykach firmy Microsoft (pochwały dla AlejandroR za doskonałe wyniki). Tutaj są trzy kategorie modeli:
Oczywiście MVC to paradygmat, który występuje w różnych odmianach. To, co tutaj opisuję, to MVC zajmujące tylko górną warstwę, zobacz ten artykuł w Wikipedii
źródło
Jeśli używasz Dependency Injectors, Twoja logika biznesowa przejdzie do nich, dzięki czemu otrzymasz schludne i czyste kontrolery.
źródło