Czy w aplikacji MVC kontroler lub model powinien obsługiwać dostęp do danych? [zamknięte]

_{dla twojej wiadomości, moim głównym językiem jest PHP, więc możesz wziąć to wszystko z przymrużeniem oka.}

Logika biznesowa w wzorcach inspirowanych MVC i MVC musi być w warstwie modelu. I tak, model ma być warstwą, a nie klasą lub obiektem.

Większość logiki rezydowałaby w obiektach domeny , ale niektóre z nich trafiałyby do usług , które powinny na przykład być strukturami "najwyższego poziomu" w warstwie modelu, poprzez które warstwa prezentacji (widoki i kontroler) wchodzi w interakcje z warstwą modelu.

Usługi powinny również ułatwiać interakcję między abstrakcjami pamięci masowej (mapery danych, obiekty dostępu do danych, jednostki pracy i/lub repozytoria ) oraz obiekty domeny. Struktury te zajmowałyby się trwałym i czasowym przechowywaniem oraz integralnością danych.

Ten rodzaj separacji upraszcza zarówno konserwację, jak i testowanie bazy kodowej. Zyskujesz możliwość łatwego testowania logiki domeny, bez dotykania bazy danych(lub jakiejkolwiek innej formy przechowywania.

Kontrolery (i równoważne struktury z innych wzorców MVVM i MVP) powinny wydobywać informacje z żądania użytkownika i zmieniać stan warstwy modelu (poprzez pracę z usługami) oraz widok.

Jeśli zaimplementujesz MVP lub MVVM, to Komponenty podobne do kontrolera będą miały dodatkowe obowiązki, w tym transfer danych z warstwy modelu do widok, ale w klasycznych i Model2 wzorcach MVC Widok ma być aktywną strukturą, która żąda danych z warstwy modelu.

Jeśli chodzi o generowanie JSON, to faktycznie powinno się zdarzyć w widoku. widoki powinny zawierać całość (lub Większość, w zależności od sposobu użycia szablonów) logiki prezentacji. Powinien pozyskiwać informacje z warstwy modelu (bezpośrednio lub za pośrednictwem pośredników) i na podstawie tych informacji generować odpowiedź (czasami tworzenie go z wielu szablonów). JSON byłby tylko innym formatem odpowiedzi.

_{istnieje ogromny wpływ (i głównie - negatywne) przez Rails framework, który został wydany w 2005th. Jego pierwotnym celem było stworzenie frameworka do prototypowania-szybkiego stworzenia kodu odrzucającego. Aby to osiągnąć, uprościli wzór do punktu, w którym rozdzielenie obaw zostało złamane.}

_{zastąpiły warstwę modelu zbiorem aktywnych rejestruj struktury, które można łatwo wygenerować i połączyć funkcjonalność widoku w kontrolerze, pozostawiając szablony jako zamiennik pełnego widoku. Było to idealne rozwiązanie dla początkowego celu, ale kiedy zaczęło się rozprzestrzeniać w innych obszarach, wprowadziło wiele błędnych wyobrażeń na temat wzorców projektowych inspirowanych MVC i MVC, takich jak "widok to tylko szablon" i "model to ORM".}

Twoje metody kontrolera powinny być tak cienkie, jak to możliwe, co oznacza, że dostęp do danych należy do modelu (a dokładniej do obiektu repozytorium).

Jeśli piszesz dowolny kod Linq w kontrolerach, tworzysz zależność, która będzie musiała zostać zmodyfikowana, jeśli zmieni się struktura witryny, i potencjalnie jesteś powielanie kodu dostępu do danych. Ale GetCustomer w modelu jest nadal GetCustomer, bez względu na to, gdzie dzwonisz z kontrolerów. Czy to ma sens?

Logika biznesowa, która jest bardziej rozbudowana niż zwykły dostęp do danych, może być umieszczona we własnej warstwie logiki biznesowej, która jest uważana za część modelu.

Model powinien obsługiwać dostęp do danych.

From MSDN :

Modele. Obiekty modelu są częściami aplikacji, które implementują Logika dla domeny danych aplikacji. Często modeluj obiekty pobranie i zapisanie stanu modelu w bazie danych . Na przykład produkt obiekt może pobierać informacje z bazy danych, operować na niej i następnie zapisz zaktualizowane informacje z powrotem do tabeli produktów w SQL Baza serwerów.

W MVC model odpowiada za obsługę dostępu do danych. Pro polega na tym, że cały kod dostępu do danych jest logicznie zamknięty przez model. Jeśli umieścisz kod dostępu do danych w kontrolerze, będziesz nadmuchiwał kontroler i łamał wzór MVC.