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.
Jeśli klasy „modelowe” są słabo zaimplementowane, tak, twoja obawa jest istotna. Klasa modelowa nie powinna wykonywać poczty elektronicznej (zadania związane z infrastrukturą).
Prawdziwe pytanie brzmi, co oznacza modelowanie w MVC. Nie ogranicza się do klas POCO z kilkoma metodami. Model w MVC oznacza logikę danych i biznesową. Traktuj to jako nadzbiór klasycznych podstawowych modeli POCO.
Widok ==== Kontroler ==== Model ---> Warstwa procesów biznesowych -> Modele podstawowe
Wrzuć zestawy infrastruktury i warstwy dostępu do danych i użyj wstrzyknięcia, aby przekazać to do BPL, a Twój proces używa MVC zgodnie z przeznaczeniem.
BPL może wywoływać wzorce UoW / repozytorium, wykonywać reguły biznesowe i wywoływać funkcje infrastruktury za pomocą wstrzykniętych obiektów lub wzorców interfejsów.
Dlatego zalecenie, aby kontroler był chudy, nie oznacza, że klasa „person” w klasycznym modelu Core powinna mieć 50 metod i bezpośrednio wywoływać Email. Masz rację, myśląc, że to źle.
Nadal może być wymagane, aby kontroler utworzył wystąpienie i wstrzyknął klasy infrastruktury do warstwy BPL lub warstwy rdzeniowej, jeśli zostanie wywołana bezpośrednio. Powinna istnieć warstwa biznesowa lub przynajmniej klasy koordynujące wywołania w klasach klasycznego modelu obiektów. Cóż, to i tak mój "widok" ;-)
Ogólne podejście do MVC opis wiki http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
Mały blog, który mówi o „M” w MVC. http://www.thedeveloperday.com/skinny-controllers/
źródło
Myślę, że można dokonać rozróżnienia między jednym grubym modelem (prawdopodobnie nazwanym aplikacją lub aplikacją) a kilkoma modelami grubymi podzielonymi na logiczne grupy (biznes, klient, zamówienie, wiadomość). To ostatnie dotyczy struktury moich aplikacji, a każdy model z grubsza odpowiada tabeli bazy danych w relacyjnej bazie danych lub kolekcji w bazie danych dokumentów. Te modele obsługują wszystkie aspekty tworzenia, aktualizowania i manipulowania danymi, które tworzą model, niezależnie od tego, czy jest to komunikacja z bazą danych, czy wywołanie interfejsu API. Sterownik jest bardzo cienki, odpowiedzialny za niewiele więcej niż wywołanie odpowiedniego modelu i wybranie szablonu.
źródło