Gdzie jest M w MVC?

14

Próbuję przekształcić moją aplikację w MVC, ale utknąłem w części M.

W aplikacji opartej na bazie danych model jest zaimplementowany w kodzie aplikacji, prawda?

Ale co jest w bazie danych - czy to też nie jest model?

(Nie używam bazy danych jako prostej składnicy obiektów - dane w bazie danych są zasobem przedsiębiorstwa).


źródło
I'm not using the database as a simple object store. Zgaduję, że to oznacza pewną logikę biznesową w bazie danych, w postaci procedur przechowywanych. Teoretycznie jest to sprzeczne z MVC, ale w praktyce nie ma to znaczenia.
yannis
@YannisRizos - w DB jest BL, ale miałem na myśli to, że chcę, aby dane w DB miały życie i znaczenie poza aplikacją.
3
I want the data in the DB to have a life and meaning beyond the application.Co?
yannis,
2
@YannisRizos - na pewno byłbym wdzięczny za pomoc w przeredagowaniu tego oświadczenia. Dane są zasobem przedsiębiorstwa, prawda? To nie należy do aplikacji - więc aplikacja nie może utworzyć jakiś szalony nieznormalizowana model, który sprawia, że bardzo łatwo dla aplikacji , jeśli sprawia, że ponowne wykorzystanie danych z innych aplikacji bardzo trudne. Jakieś sugestie?
1
To nie będzie problem, jeśli istnieje format dla czegokolwiek, co musi zostać udostępnione, staje się to częścią wymagań dotyczących formatu pamięci. Wszystko, co w przyszłości potrzebuje tego w innym formacie, może mieć zadanie ETL lub przekształcić je w DAL.
StuperUser

Odpowiedzi:

46

Tak, zarówno model w kodzie, jak i baza danych to „Model”.

Model ma związek z tym, co twoja aplikacja „JEST”, a kontroler jest tym, co „robi”. Każdy kod zajmujący się bezpośrednią trwałością bazy danych jest uważany za Model.

Uwaga: MVC jest wzorem , więc nie przesadzaj z tym. Łatwo jest zaangażować się w tworzenie MVC we właściwy sposób, ale pod koniec dnia jest to tylko sposób myślenia! Oznacza to utrzymanie logiki biznesowej poza bazą danych i interfejsem użytkownika - to wszystko. Przed MVC ludzie umieszczali logikę biznesową na swoich stronach internetowych, kiedy powinna ona znajdować się na serwerze, lub mieliby kilka skryptów odpalających w bazie danych, wykonujących logikę biznesową wraz z kodem trwałości. MVC powstało, aby zachęcić ludzi do myślenia w taki sposób, aby ich kod był wielokrotnego użytku, więc nie daj się zbytnio wciągnąć w szczegóły.

Ryan Hayes
źródło
15
Więc z punktu widzenia C i V, że baza danych jest tylko szczegółem implementacji M?
Zdecydowanie. Ładnie sformułowane.
herby
3
@MattFenwick Z punktu widzenia C i V nie ma bazy danych. Korzystasz z bazy danych jako czegoś więcej niż do przechowywania danych, w kategoriach MVC baza danych to tylko przechowywanie danych. Ale to idealnie, jeśli pasuje do twojej aplikacji.
yannis,
5
+1 za „Don't overthink mvc”
Javier
2
„trzymaj logikę biznesową poza bazą danych i interfejsem użytkownika” - to
David Murdoch
17

Trygve Reenskaug napisał wstępne prace opisujące wzór MVC w 1978 roku. Model w jego opisie był modelem obiektowym reprezentującym rzeczywiste obiekty, zjawiska i pojęcia. W scenariuszu aplikacji opartej na bazie danych model jest rzutowaniem danych. Mówiąc najprościej, model to klasy i ich relacje, którymi zajmuje się twoja aplikacja.

W praktyce w MVC zwykle stosuje się dwa modele: model domeny (co jest mapowane do bazy danych) i model aplikacji (zwany również w dzisiejszej terminologii modelem widoku). Model aplikacji jest rzutem modelu domeny, który zawiera również dane specyficzne dla widoku do renderowania widoku. To podejście nazywa się MMVC . Kontroler bezpośrednio współpracuje z modelem domeny i przedstawia model aplikacji w widoku. We wzorze MVVM model aplikacji i kontroler są połączone.

Michael Brown
źródło
+1: Najbardziej podoba mi się ta odpowiedź. The model is a projection of your data.Baza danych jest zaprojektowana do przechowywania danych w najbardziej efektywny sposób w celu uzyskania dostępu i indeksowania. Zamiast tego model powinien być zaprojektowany wokół domeny biznesowej.
Joel Etherton,
Parę sekund zajęło mi przeanalizowanie the Domain Model (what's mapping to your database). Niezła odpowiedź!
2
+1 To świetny opis różnych smaków, w które ewoluowało MVC.
Ryan Hayes
Dzięki chłopaki. Podczas pisania mojej książki nurkowałem głęboko w tym temacie. Cieszę się, że to ma sens!
Michael Brown,
3
  1. Nie potrzebujesz bazy danych dla MVC. Jeśli Twój model rozmawia z bazą danych, to świetnie. Może również utrzymywać się do płaskiego pliku lub wcale.

  2. Model służy do przechowywania danych w aplikacji. Będziesz także chciał użyć modelu do wykonywania obliczeń i weryfikacji jego danych. Na przykład masz model FinancePayment z właściwościami takimi jak stopa procentowa, termin i zasada. Możesz dodać metodę getMonthlyPayment () do swojego modelu, aby obliczyć miesięczną płatność. Nie chcesz tego robić w kontrolerze lub widoku.

  3. Widok powinien być dość głupi, albo nie mieć żadnej logiki, albo używać tylko prostego powiązania danych (patrz Wzorce widoku pasywnego i Wzorce kontrolera na stronie Martina Fowlera ). Widok wywołuje zdarzenia, gdy użytkownik wykonuje różne czynności, takie jak kliknięcie przycisku.

  4. Kontroler odpowiada za obsługę zdarzeń (uruchamianie kodu, gdy użytkownik kliknie przycisk Zapisz) oraz za ustawianie właściwości modelu, a także za polecenie modelowi załadowania i zapisania się (jeśli używa trwałości). Kontroler nie powinien wykonywać obliczeń na danych modelu. Jednak w kontrolerze możesz wykonać pewne obliczenia w imieniu widoku, na przykład „if model.profit () <0, a następnie widget.colour = 'red'”

  5. Powinieneś być w stanie przełączyć się do wersji wiersza polecenia swojej aplikacji bez zmiany modeli i bez utraty funkcjonalności modeli.

za. Prawdopodobnie powinieneś być w stanie przełączyć się na wersję mobilną aplikacji (w przeciwieństwie do wersji na komputery), zmieniając tylko widoki (a nie kontrolery lub modele). Powinieneś być w stanie testować jednostkowo swoje modele i kontrolery bez ram testowych GUI.

Neil McGuigan
źródło
Tak jest! To jest bardzo jasne.
2

Model to kod, który ma połączenie z V i C w interfejsie użytkownika oraz w pamięci trwałej (może to być wszystko, od plików po bazy danych SQL / NoSQL) w wewnętrznej bazie danych. Nie tylko kod ładuje się z bazy danych i przechowuje do bazy danych (co jest jednym z nieporozumień modelu), to kod, który faktycznie wykonuje całą „domenę” - wybiera, filtruje, zmienia, oblicza, decyduje o dane. Obejmuje całą logikę aplikacji inną niż interfejs użytkownika.

herby
źródło
Surowe dane, które chcesz zachować. W każdej organizacji, która najlepiej pasuje do twojego modelu. Model jest interfejsem API, dzięki któremu logika aplikacji jest aktywna. Ta baza danych jest miejscem przechowywania (nieożywionych) danych. Jeśli jest to możliwe dla Twojej aplikacji (nie wiem, jaki to rodzaj aplikacji), spróbuj przestać myśleć o niej jako o „aplikacji opartej na bazie danych”, ale po prostu „aplikacji”, która wykorzystuje bazę danych jako sposób utrwalić dane modułu. Wiele problemów wynika z „ikonowania” bazy danych - jest to nic innego jak przechowywanie danych dla modelu; możesz go porzucić, zrestrukturyzować lub wymienić, jeśli to pomoże.
herby
(powyżej dotyczy tylko scenariuszy, w których dane w bazie danych nie są współużytkowane z inną aplikacją)
herby
Przepraszam za słaby wybór słów w moim komentarzu - chciałem powiedzieć, że nie jestem pewien, co jest w bazie danych w odniesieniu do MVC . Czy baza danych jest poza MVC? Czy to część modelu? Czy jest to część V lub C (prawdopodobnie nie, ale masz rację).
Widzę. Prawdopodobnie wywnioskowałeś z mojej odpowiedzi, że możesz zobaczyć, że jest to część modelu, która służy do utrwalenia danych aplikacji przetwarzanych przez kod z modelu. (Widzę EDYCJA): Jeśli ta baza danych musi przeżyć aplikację, to spójrz na bazę danych jako usługę zewnętrzną, z którą model musi się komunikować, uzyskać dane do obliczeń, a także odesłać je z powrotem.
herby
W skrajnym przypadku, gdy logika biznesowa znajduje się w samym DB, możesz mieć bardzo cienki model, który przeważnie przekazuje DB, lub nawet powiedzieć, że db jest twoim modelem (ale wtedy powinna mieć całą logikę).
herby
2

Przyjmowanie bardzo uproszczonego i idealistycznego poglądu.

Model jest ogólnie postrzegany jako model domeny (w przybliżeniu firmy), a nie jako model danych. Te mogą wyglądać podobnie, ale nie są one całkowicie przywiązany do siebie.

Widok powinien być modelem interfejsu aplikacji, a kontroler powinien być modelem przepływu z jednego widoku do drugiego.

Logika biznesowa powinna być całkowicie zamknięta w modelu, bez względu na to, czy będzie to baza danych, czy kod. Chociaż niektóre logiki biznesowe mogą być powtarzane w widoku lub kontrolerze, z różnych powodów powinno być możliwe (i bezpieczne) całkowite usunięcie tych dwóch komponentów i umieszczenie innego interfejsu użytkownika na swoim miejscu.

pdr
źródło
1

Według mnie MVC to tylko opis wzorca architektonicznego aplikacji klienckiej. Zdjęcie tutaj w Wikipedii pokazuje to tylko:

http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

Oczywiście, jeśli masz części aplikacji zaimplementowane w „procedurach przechowywanych”, wówczas kod bazy danych może być również częścią modelu, a nawet kontrolera (w zależności od tego, co robi kod). Ale jeśli tak nie jest, baza danych jest wyraźnie „poza MVC”, tak jak to powiedziałeś.

Doktor Brown
źródło
1
But then, what is in the database -- is that not also the model?

Nie, nie jest. Model zarządza zachowaniem i danymi domeny aplikacji”. Często model łączy się z bazą danych tak, ale w żadnym wypadku nie jest to wymóg. Model jest nową warstwą między aplikacją a bazą danych. Backend może być zestawem obiektów próbnych, XML lub cokolwiek innego, co obsługuje utrwalanie danych.

Odsprzęgając warstwy, zyskujesz znacznie większą elastyczność w korzystaniu z lepszych praktyk testowania jednostkowego, czyniąc kod łatwiejszym do zarządzania (EG SQL zastępuje Oracle), oprócz innych korzyści.

To samo dotyczy kontrolera. MVC definiuje kontroler jako pośrednika między dwiema warstwami. W MVC nie zdefiniowano „warstwy biznesowej”. Zamiast tego dodajesz własne. MVC nie zawiera wszystkich warstw wymaganych do zbudowania większości aplikacji. To tylko ogólne wytyczne dla podstawowej struktury.

Te separacje są kluczem do umożliwienia odwrócenia kontroli do funkcji.

P.Brian.Mackey
źródło
+1 za doskonałą i bardzo pouczającą odpowiedź; chociaż sugerowałbym, że ostatnie zdanie zasługuje na wyjaśnienie. IoC niekoniecznie jest tak powszechnie znany i rozumiany, więc może wprowadzić nieco zamieszania. Naprawdę przydatne wyjaśnienie tego, co masz na myśli, prawdopodobnie wykracza poza zakres rozsądnej odpowiedzi SE, ale mnie zaskoczyło.
Adam Crossland,
Jeśli jednak umieścisz logikę biznesową w procedurach przechowywanych, wówczas tak, baza danych obejmuje model. (Osobiście nie zalecałbym takiego podejścia.)
Roy Tinker,
1
@ Roy Tinker - Nie, to nie ma znaczenia. Model jest koncepcyjnie odrębny. Gdzieś w warstwie będą istoty integrujące się z bazą danych. Te jednostki powinny pozostać oddzielone od innych jednostek, które istnieją w modelu, które mają inne relacje (na przykład Mock). Administrator powinien wywoływać wywołania do Modelu w taki sposób, aby nie miał wiedzy o tym, jak i skąd pochodzą dane. To ustalenie powinno raczej odbywać się za pomocą wstrzykiwania zależności i IoC (w zasadzie jest to interfejs, który można powiązać z różnymi backendami, szyderstwem lub DB).
P.Brian.Mackey,
1

Baza danych jest szczegółem implementacji modelu. Model powinien być pełnym modelem domeny i powinien łączyć dane i proces. Oddzielenie powinno dotyczyć różnic dotyczących obaw, a nie między procesem a danymi związanymi z tym procesem.

Zobacz także: http://martinfowler.com/bliki/AnemicDomainModel.html

Paris Sinclair
źródło
0

W rzeczywistości jest to bardzo proste, „Model” reprezentuje abstrakcję interfejsu danych. Dlatego:

  • Bazy danych są traktowane jako część modelu , ale nie sam model
  • Dane modelu mogą pochodzić z baz danych, plików, usług internetowych, a nawet mogą być wyśmiewane.
  • Klasy modeli w MVC, HMVC lub podobnych ramach powinny przechowywać zapytania (patrz zasada „gruby model, chudy kontroler” [ 1 ] [ 2 ] [ 3 ])

I - jeśli mam rację - dlatego, gdy ktoś odnosi się do modeli spoza kontekstu MVC, to ktoś najprawdopodobniej odnosi się do struktury danych (tj. Schematu ).

dukeofgaming
źródło
0

Myślę, że M zawiera logikę i przechowuje dane w DB. Kontroler wywołuje, który moduł zostałby wykonany, a ten moduł wykonuje logikę i przechowuje dane w DB (może być w warstwie stałej), a następnie moduł zwraca wartość do V.

Mark xie
źródło
0

M (odel) w MVC powinien uchwycić model firmy / domeny w jednym miejscu.

Idealnie powinno to obejmować reguły biznesowe domeny, a także jej strukturę.

C (kontroler) powinien idealnie zajmować się jedynie mediowaniem informacji o modelu biznesowym do prezentacji (np. Widok) i przechwytywaniem danych wejściowych użytkownika z V (iew) w celu zainicjowania zmian w stanie modelu.

Warstwa bazy danych zajmuje się (a raczej powinna tylko radzić sobie) z utrzymywaniem się stanu modelu w danym momencie.

W związku z tym nie jest to coś, co należy do modelu lub części kontrolnej wzorca MVC, ale jest to całkowicie osobna kwestia, którą można wdrożyć w sposób domyślny poprzez transparentne utrwalenie wszelkich zmian w modelu (w funkcji fasady, zapewniając interakcje z twoim modelem do kontrolera) lub, jak to często bywa, wywoływane jawnie przez kontrolera po zakończeniu wprowadzania mutacji w modelu.

Roland Tepp
źródło
0

Model w idealnym świecie powinien zawierać tylko logikę biznesową, modeluje prawdziwy obiekt, taki jak Dom. Jednak w prawie wszystkich okolicznościach model musi utrwalić swoje dane do pewnego miejsca.

Interakcje między modelem a przechowywanymi danymi mogą zachodzić na osobnej warstwie danych lub bezpośrednio w modelu, co ma miejsce w przypadku korzystania z ORM (Object Relational Mapper). Innymi słowy, model łączy się bezpośrednio z bazą danych lub przekazuje dane do innego obiektu „dostępu do danych”, który łączy się z bazą danych.

ORM (Object Relation Mapper) mapuje pola w tabeli bazy danych na atrybuty obiektu modelu, udostępniając metody pobierające i ustawiające. W tym przypadku nie ma osobnej warstwy danych, a model jest bezpośrednio odpowiedzialny za utrwalenie swoich danych.

Oto Rubinowy przykład wykorzystujący ActiveRecordpopularny ORM:

class House < ActiveRecord::Base
end

house = House.new
house.price = 120000
house.save

Priceto pole w housestabeli, które jest automatycznie wykrywane, przez ActiveRecordco dodaje obiekt pobierający i ustawiający do obiektu. Po savewywołaniu wartość atrybutu ceny jest utrwalana w bazie danych.

Z mojego punktu widzenia zaletą posiadania warstwy danych jest to, że dostajesz punkt, w którym możesz manipulować danymi, zanim dotrze do modelu, model ma mniej powodów do zmartwień, ma mniej obowiązków. Na przykład może być konieczne połączenie danych z kilku niekompatybilnych źródeł danych, jest to coś, czego ORM nie może łatwo obsłużyć.

Główną wadą jest kolejna warstwa abstrakcji do zarządzania, jeśli jej nie potrzebujesz, nie zawracaj sobie głowy, zachowaj prostotę. Mniej ruchomych części, mniej błędów.

Kris
źródło
-1

Tak masz rację.

(Kontroler widoku modelu)

Architektura do budowania aplikacji, które oddzielają dane (model) od interfejsu użytkownika (widok) i przetwarzania (kontroler).

W praktyce widoki MVC i kontrolery są często łączone w jeden obiekt, ponieważ są ze sobą ściśle powiązane. Według MSDN

Kontroler interpretuje dane wejściowe myszy i klawiatury od użytkownika, informując model i / lub the view to change as appropriate.

Sprawdź ten schemat:

wprowadź opis zdjęcia tutaj

Na przykład kod kontrolera sprawdza poprawność żądania danych i powoduje, że jest ono zwracane w widoku. Obiekty kontrolera widoku są powiązane tylko z jednym modelem; jednak,a model can have many view-controller objects associated with it.

Niranjan Singh
źródło
4
In practice, MVC views and controllers are often combined into a single object because they are closely related.Jeśli to robisz, robisz to źle ...
yannis
Skąd jest schemat? A skąd pochodzi ta definicja? Nie kopiuj tylko materiałów z Internetu bez odpowiedniego przypisania.
yannis,
@Yannis Rizos - Cytuje dokumentację stwardnienia rozsianego. Jest to trochę poza kontekstem, ale mówią, że aplikacje nie-sieciowe często mają połączenie widoku / kontrolera, ale aplikacje internetowe mają bardzo wyraźne rozróżnienie. Jest to prawdopodobnie jeden z powodów, dla których MS nie popycha MVC dla swoich aplikacji Windows (zamiast tego MVVM), tylko aplikacje internetowe. msdn.microsoft.com/en-us/library/ff649643.aspx
P.Brian.Mackey
1
@ P.Brian.Mackey Podejrzewałem, że stwardnienie rozsiane było w jakiś sposób za tym: P
yannis
Zredagowałem twoją odpowiedź, dołączając podany link @ P.Brian.Mackey. Cytowanie źródeł zewnętrznych jest w porządku, ale musisz podać linki do nich. Również MVVM może być bardzo podobny do MVC, ale nie jest to ten sam wzorzec. W widokach MVC kontrolery nigdy nie powinny być łączone w jeden obiekt ...
yannis