To może nie być najlepszy pomysł, aby spojrzeć na Railsy jako podstawę wzorca projektowego MVC. Wspomniany szkielet został stworzony z pewnymi nieodłącznymi niedociągnięciami (opisałem go w innym poście ), a społeczność dopiero teraz zaczęła zajmować się opadem. Możesz spojrzeć na rozwój DataMapper2 jako pierwszy duży krok.
Trochę teorii
Wydaje się, że osoby udzielające tej rady są dotknięte dość powszechnym błędnym przekonaniem. Zacznę więc od wyjaśnienia: Model we współczesnym wzorcu projektowym MVC NIE jest klasą ani obiektem. Model jest warstwą.
Podstawową ideą wzorca MVC jest Separacja problemów, a pierwszym krokiem jest podział na warstwę prezentacji i warstwy modelu. Podobnie jak warstwa prezentacji dzieli się na kontrolery (instancje odpowiedzialne za obsługę danych wejściowych użytkownika), widoki (instancje, odpowiedzialne za logikę interfejsu użytkownika) i szablony / układy, tak również warstwa modelu.
Główne części, z których składa się warstwa modelu, to:
Obiekty domeny
Znane również jako jednostki domeny, obiekty biznesowe lub obiekty modeli (nie podoba mi się ta druga nazwa, ponieważ po prostu zwiększa zamieszanie). Struktury te są zwykle mylnie określane jako „modele”. Są odpowiedzialne za zawarcie reguł biznesowych (cała matematyka i walidacja dla określonej logiki jednostki domeny).
Abstrakcje dotyczące pamięci masowej:
Zwykle implementowane przy użyciu wzorca mapowania danych (nie mylić z ORMami , które nadużyły tej nazwy). Te instancje zwykle mają za zadanie przechowywanie i pobieranie informacji do obiektów domeny. Każdy obiekt domeny może mieć kilka maperów, tak jak istnieje kilka form przechowywania (DB, pamięć podręczna, sesja, pliki cookie, / dev / null).
Usługi:
Struktury odpowiedzialne za logikę aplikacji (czyli interakcję między obiektami domeny i interakcję między obiektami domeny i abstrakcji pamięci masowej). Powinny działać jak „interfejs”, przez który warstwa prezentacji współdziała z warstwą modelu. To jest zwykle to, co w kodzie podobnym do Railsów trafia do kontrolerów.
Istnieje również kilka struktur, które mogą znajdować się w przestrzeniach między tymi grupami: DAO , jednostki pracy i repozytoria .
Aha ... i kiedy mówimy (w kontekście sieci) o użytkowniku, który współdziała z aplikacją MVC, to nie jest on człowiekiem. „Użytkownik” to w rzeczywistości Twoja przeglądarka internetowa.
A co z bóstwami?
Zamiast mieć jakiś przerażający i monolityczny model do pracy, kontrolery powinny współdziałać z usługami. Przekazujesz dane wprowadzone przez użytkownika do określonej usługi (na przykład MailServicelub RecognitionService). W ten sposób kontroler zmienia stan warstwy modelu, ale odbywa się to za pomocą przejrzystego API i bez bałaganu w strukturach wewnętrznych (co spowodowałoby nieszczelną abstrakcję).
Takie zmiany mogą albo wywołać natychmiastową reakcję, albo wpłynąć tylko na dane, których instancja widoku żąda z warstwy modelu, lub jedno i drugie.
Każda usługa może współdziałać z dowolną liczbą (choć zazwyczaj jest to tylko kilka) abstrakcji obiektów domeny i pamięci. Na przykład RecogitionServicenie mogliby mniej przejmować się abstrakcyjnymi danymi dotyczącymi przechowywania artykułów.
Uwagi końcowe
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 jasno zrozumiałą architekturę.
Pamiętaj jednak: MVC nie jest przeznaczony do małych aplikacji. Jeśli piszesz stronę księgi gości przy użyciu wzorca MVC, robisz to źle. Ten wzorzec jest przeznaczony do egzekwowania prawa i porządku w zastosowaniach na dużą skalę.
Ten post może być odpowiedni dla osób, które używają PHP jako języka podstawowego . To nieco dłuższy opis warstwy modelu z kilkoma fragmentami kodu.