ASP.NET MVC - czy logika biznesowa powinna istnieć w kontrolerach?

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.

Logika biznesowa naprawdę powinna być w modelu. Powinieneś dążyć do grubych modelek, chudych kontrolerów.

Na przykład zamiast mieć:

public interface IOrderService{
    int CalculateTotal(Order order);
}

Wolałbym mieć:

public class Order{
    int CalculateTotal(ITaxService service){...}        
}

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:

public class OrdersController{
    public OrdersController(ITaxService taxService, IOrdersRepository ordersRepository){...}

    public void Show(int id){
        ViewData["OrderTotal"] = ordersRepository.LoadOrder(id).CalculateTotal(taxService);
    }
}

Czy jakoś tak.

Podoba mi się diagram przedstawiony przez Microsoft Patterns & Practices . I wierzę w przysłowie „Obraz jest wart tysiąca słów”.

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.

Możesz sprawdzić ten niesamowity samouczek Stephena Walther, który pokazuje Validating with a Service Layer .

Dowiedz się, jak przenieść logikę walidacji z akcji kontrolera do osobnej warstwy usług. W tym samouczku Stephen Walther wyjaśnia, w jaki sposób można zachować ostry rozdział problemów, izolując warstwę usług od warstwy kontrolera.

Logika biznesowa nie powinna być zawarta w kontrolerach. Kontrolery powinny być tak chude, jak to tylko możliwe, najlepiej podążać za wzorcem:

1. Znajdź jednostkę domeny
2. Działaj na rzecz podmiotu domeny
3. Przygotuj dane do przeglądania / zwracania wyników

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:

• Model widoku : jest to po prostu zbiór danych, z minimalną logiką przekazywania danych zi do widoków, jeśli w ogóle, zawiera podstawową walidację pola.
• Model domeny : model gruby z logiką biznesową, działa na jednej lub wielu jednostkach danych (tj. Jednostka A w danym stanie niż akcja na jednostce B)
• Model danych : model uwzględniający pamięć masową, logika zawarta w pojedynczej encji odnosi się tylko do tej jednostki (tj. Jeśli pole a to pole b)

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

Obecnie MVC i podobny model-view-prezenter (MVP) to wzorce projektowe separacji obaw, które mają zastosowanie wyłącznie do warstwy prezentacji większego systemu. W prostych scenariuszach MVC może stanowić podstawowy projekt systemu, sięgający bezpośrednio do bazy danych; Jednak w większości scenariuszy kontroler i model w MVC mają luźną zależność od usługi lub warstwy / warstwy danych. Chodzi o architekturę klient-serwer

Jeśli używasz Dependency Injectors, Twoja logika biznesowa przejdzie do nich, dzięki czemu otrzymasz schludne i czyste kontrolery.