Grube Modelki i chude Kontrolery brzmi jak tworzenie God models [closed]

_{to może nie być najlepszy pomysł, aby spojrzeć na Rails jako podstawę wzorca projektowego MVC. Wspomniany framework został stworzony z pewnymi nieodłącznymi niedociągnięciami (trochę rozwinąłem go w innym poście ) i społeczność dopiero teraz zaczęła zajmować się Falloutem. Możesz spojrzeć na rozwój DataMapper2 jako pierwszy ważny krok.}

Jakaś teoria

Podstawową ideą wzorca MVC jest rozdzielenie obaw a pierwszym krokiem w nim jest podział między warstwą prezentacji i warstwą modelu. Podobnie jak warstwa prezentacji dzieli się na Kontrolery( instancje, odpowiedzialne za wprowadzanie danych przez użytkownika), widoki (instancje, odpowiedzialne za logikę interfejsu użytkownika) i szablony/układy, tak samo model warstwa.

Główne części, z których składa się warstwa modelu, to:

• Domain Objects

  Znane również jako encje domeny, obiekty biznesowe lub obiekty modelowe(nie lubię tej drugiej nazwy, ponieważ tylko dodaje zamieszania). Te struktury są tym, co ludzie zwykle błędnie nazywają "modelami". Są one odpowiedzialne za przechowywanie reguł biznesowych (cała matematyka i Walidacja dla określonej jednostki logiki domeny).

• Przechowywanie Abstrakcje:

  Zwykle zaimplementowane przy użyciu wzorcadata mapper (nie mylić z ORMs , które nadużywały tej nazwy). Instancje te zwykle mają za zadanie przechowywanie informacji-z obiektów domain i ich pobieranie-do obiektów domain. Każdy obiekt domeny może mieć kilka maperów, podobnie jak istnieje kilka form przechowywania (DB, cache, session, cookies, / dev / null).

• Usługi:

  Struktury odpowiedzialne za logikę aplikacji (czyli, interakcja między obiektami domenowymi i interakcja między obiektami domenowymi i abstrakcjami pamięci). Powinny one działać jak "interfejs", przez który warstwa prezentacji współdziała z warstwą modelu. To zwykle jest to, co w kodzie typu Rails kończy się w kontrolerach.

Istnieje również kilka struktur, które mogą znajdować się w przestrzeniach między tymi grupami: DAOs, jednostki pracy i repozytoria .

_{Oh ... a kiedy mówimy (w kontekście sieci) o użytkowniku , który współdziała z aplikacją MVC, nie jest człowiekiem. "Użytkownik" to w rzeczywistości twoja przeglądarka internetowa.}

Zamiast mieć jakiś straszny i monolityczny model do pracy, Kontrolery powinny współdziałać z usługami. Przekazujesz dane z danych wejściowych użytkownika do określonej usługi(na przykład MailService lub RecognitionService). W ten sposób kontroler zmienia stan warstwy modelu, ale odbywa się to za pomocą przejrzystego API i bez mieszania się z wewnętrznymi strukturami (co powodowałoby nieszczelną abstrakcję).

Takie zmiany mogą spowodować natychmiastową reakcję lub wpłynąć tylko na dane żądane przez instancję widoku z warstwy modelu, lub oba te czynniki.

Każda usługa może wchodzić w interakcje z dowolną liczbą (choć zazwyczaj jest to tylko garstka) obiektów domeny i abstrakcji pamięci masowej. Na przykład RecogitionService nie może się mniej przejmować abstrakcjami przechowywania artykułów.

Zamknięcie uwagi

W ten sposób otrzymujesz aplikację, która może być testowana jednostkowo na dowolnym poziomie, ma niskie sprzężenie (jeśli jest poprawnie zaimplementowana) i ma wyraźnie zrozumiałą architekturę.

Należy jednak pamiętać: MVC nie jest przeznaczony dla małych aplikacji. Jeśli piszesz stronę księgi gości za pomocą wzorca MVC, robisz to źle. Ten wzór jest przeznaczony do egzekwowania prawa i porządku w aplikacjach na dużą skalę.

_{dla osób, które używają PHP jako języka podstawowego, ten post może być istotny. Jest to nieco dłuższy opis warstwy modelu z kilkoma fragmentami kodu.}