Gdzie jest M w MVC?

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).

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.

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.

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.

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.

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.

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ś.

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.

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

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 ).

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.

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.

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.

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:

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.