Wszystko to zależy od intencji i wymagań aplikacji.

To powiedziawszy, oto moja propozycja dla" średniej skali " (nie lokalnej restauracji, a nie Twitter/Facebook) aplikacji internetowych.

1. Lean Domain Modeling

   Suche obiekty w stylu poco, najlepiej ignorujące architekturę MVC Twojej aplikacji internetowej, aby pozostały jak najbardziej luźno powiązane z konkretną implementacją.być może nawet przepakować bibliotekę klas-zdolną do wykorzystania w aplikacja zewnętrzna, np. REST API poprzez usługę WWW WCF).

   " Model " w MVC najdokładniej oznacza model, którego kontroler jest świadomy, a więc model przeznaczony dla widoku.

   W mniejszych (często Samouczkowych) aplikacjach modele encji "warstwy modelu aplikacji/domeny" są często tymi samymi instancyjnymi obiektami, które kontroler wysyła do widoku.

   W większych aplikacjach programiści często stosują zasady architektury MVVM i zacznij używać oddzielnych obiektów modelu widoku. Kontrolery często nazywają usługi średniego poziomu, które współpracują z niewidocznymi podmiotami poniżej. W tym scenariuszu M W MVC najdokładniej oznacza model widoku.

2. Solidna Warstwa Serwisowa

   Nie oznacza to } } logiki, ale dobrze napisane usługi jednego celu. Podczas gdy kodowanie logiki biznesowej w usługach poza modelem jest nieco bardziej "proceduralne" niż czyste "OOP", bardzo pomaga w luźnym łączenie, Testowanie i elastyczne wdrażanie (np. n-tier deployment).

   W mojej osobistej praktyce koduję usługi zarówno w warstwie danych, co uważam za moje modelowanie behawioralne obiektów POCO (mechanika trwałości, Walidacja niskiego poziomu itp.), oraz usługi wyższego poziomu (funkcja business/workflow) bliżej mechaniki MVC.

3. Kontrolery Lean

   Upewniam się, że mój kontroler to tylko trener , ponieważ nie jest to ani Zagraj (usługi) lub gracz (model podmiotu lub model widoku), ale po prostu decyduje, kto gra na jakiej pozycji i jaką grę wykonać. Moje Kontrolery robią dwie rzeczy:

   1. Usługi połączeń, które współdziałają z modelami entity / domain

   2. Przygotuj model widoku dla odpowiedniego widoku.

   Nawet uwierzytelnione / autoryzowane działania kontrolera są wykonywane za pomocą wtryskiwanych usług / atrybutów.

EDIT 1:

Pamiętaj, że nie oznacza to, że Twój model podmiotu/domeny jest lub musi być anemiczny. Orm, repozytoria i fabryki, Walidacja lub mechanika Państwowa są mile widziane. Oznacza to tylko dla aplikacji o umiarkowanej skali, model w MVC reprezentuje model przeznaczony dla kontrolera, aby przekazać go do widoku .

Miejmy nadzieję, że ten punkt uspokoi wszystkich, którzy wierzą, że anemiczny model danych jest anty-wzorzec. W tym samym czasie Czy odzwierciedla nieco bardziej proceduralny kąt niż OOP, gdzie bardziej czyste jest włączenie zachowania w modelowanych klasach.

Nie ma "ostatecznej prawdy" , ale za pomocą tego wzorca można łatwo budować, testować i wdrażać aplikacje - przy zachowaniu dużej możliwości ponownego użycia i skalowalności.

Edytuj 2:

To powiedziane, nawet dla skromnych zastosowań, nad architekturą (że słowo kujony wymyślił?) system jest zbyt powszechny. Na instancja, owijanie ORM wzorcem repozytorium, a następnie pisanie usług do korzystania z repozytorium... wszystko to jest dobre dla oddzielenia troski i takich, ale jeśli twój projekt nie wymaga (i nie jest bardzo prawdopodobne, aby {13]}wkrótce {14]} wymagać) takich rzeczy, nie buduj go. Nie ma nic złego w pomijaniu repozytorium razem, pisząc cienkie usługi biznesowe(np. klasy zapytań) w stosunku do ORM, lub nawet gdy twój kontroler rozmawia bezpośrednio z nim. Wszystko zależy od skala.

Edytuj 3:

Chciałem zauważyć, że to wyjaśnienie i porady dotyczą kontekstu architektury MVC po stronie serwera, jak ASP.Net, nie dla klent-side frameworków takich jak Knockout czy Backbone.