Cel warstwy serwisowej i ASP.NET MVC 2

Question

Starając się zrozumieć MVC 2 i starać się, aby moja firma przyjęła go jako realną platformę do przyszłego rozwoju, ostatnio dużo czytam. Pracując z ASP.NET całkiem ekskluzywnie przez ostatnie kilka lat, miałem trochę do nadrobienia.

Obecnie rozumiem schemat repozytorium, modele, kontrolery, adnotacje danych itp. Ale jest jedna rzecz, która powstrzymuje mnie przed kompletnym zrozumieniem wystarczającym do rozpoczęcia pracy nad aplikacją referencyjną.

Pierwszy to wzór warstwy serwisowej. Czytałem wiele postów i pytań na blogu w Stack Overflow, ale wciąż nie rozumiem w pełni celu tego wzorca. Obejrzałem całą serię filmów w MVCCentral w aplikacji Golf Tracker, a także spojrzałem na opublikowany przeze mnie kod demo i wygląda na to, że warstwa usługi jest po prostu kolejnym opakowaniem w repozytorium, które nie wykonuje żadnej pracy.

Przeczytałem również ten wpis: http://www.asp.net/Learn/mvc/tutorial-38-cs.aspx i wydawało się, że w pewnym stopniu odpowiada na moje pytanie, jednak jeśli używasz adnotacji do przeprowadzenia walidacji, wydaje się to niepotrzebne.

Szukałem demonstracji, stanowisk itp., Ale nie mogę znaleźć niczego, co po prostu wyjaśnia wzór i daje mi przekonujące dowody, aby go użyć.

Czy ktoś może podać mi ocenę 2 stopnia (ok, może 5 klasa), aby użyć tego wzoru, co bym stracił, gdybym tego nie zrobił, a co zyskałbym, gdybym to zrobił?

Answer 1

W modelu MVC obowiązki są rozdzielone między 3 graczy: Model, Widok i Kontroler.

Model jest odpowiedzialny za wykonywanie czynności biznesowych, widok przedstawia wyniki działalności (dostarczając również dane wejściowe do firmy od użytkownika), podczas gdy kontroler działa jak klej między modelem a widokiem, oddzielając wnętrze funkcjonowanie każdego z drugiego.

Model jest zwykle zapisywany w kopii zapasowej przez bazę danych, więc masz dostęp do niej niektórych DAO. Twoja firma zajmuje się ... no ... biznesem i przechowuje lub pobiera dane z/z bazy danych.

Ale kto koordynuje DAO? Kontroler? Nie! Model powinien.

Wprowadź warstwę usługi. Warstwa serwisowa zapewni wysoki poziom obsługi kontrolera i będzie zarządzać innymi graczami (niższego poziomu) (DAO, inne usługi itp.) Za kulisami. Zawiera logikę biznesową Twojej aplikacji.

Co stanie się, jeśli go nie użyjesz?

Musisz gdzieś umieścić logikę biznesową, a ofiarą jest zwykle kontroler.

Jeśli kontroler jest internetowy, musi odebrać dane wejściowe i dostarczyć odpowiedzi jako żądania HTTP, odpowiedzi. Ale co jeśli chcę zadzwonić do mojej aplikacji (i uzyskać dostęp do firmy, którą zapewnia) z aplikacji Windows, która komunikuje się z RPC lub jakąś inną rzeczą? Co wtedy?

Cóż, będziesz musiał przepisać kontroler i uczynić agnostyka klienta logicznego. Ale z warstwą Usługi już to masz. Nie musisz przepisywać rzeczy.

Warstwa usług zapewnia komunikację z DTO, które nie są powiązane z konkretną implementacją kontrolera.Jeśli kontroler (bez względu na rodzaj kontrolera) dostarcza odpowiednich danych (bez względu na źródło) twoja warstwa usługowa wykona swoje zadanie, zapewniając usługę dzwoniącemu i ukrywając dzwoniącego przed wszystkimi obowiązkami logiki biznesowej.

Answer 2

Muszę powiedzieć, że zgadzam się z dpb z powyższym, otoki, tj. Warstwa usługi jest wielokrotnego użytku, mocowany, obecnie jestem w trakcie włączania tej warstwy wewnątrz mojej aplikacji ... Oto niektóre z problemów/wymagań Zastanawiam się nad (bardzo szybko: p), który może być pomocny dla ciebie ...
1. Wiele portali (np. Portal blogerów, portal klienta, portal wewnętrzny), które będą potrzebne dla wielu różnych użytkowników. Wszystkie muszą być osobnymi aplikacjami ASP.NET MVC (ważne wymaganie)
2. W samych aplikacjach niektóre wywołania do bazy danych będą podobne, metody i sposób obsługi danych z poziomu repozytorium. Bez wątpienia niektóre kontrolery z każdego modułu/portalu wykonają dokładnie lub przeciążoną wersję tego samego połączenia, stąd możliwe zapotrzebowanie na warstwę usługi (kod do interfejsów), którą następnie skompiluję w oddzielnym projekcie klasy.
3.Jeżeli utworzę oddzielny projekt klasy dla mojej warstwy usługi, być może będę musiał zrobić to samo dla warstwy danych lub połączyć ją z warstwą usługi i zachować model z dala od samego projektu sieci Web. Przynajmniej w ten sposób, gdy mój projekt rośnie, mogę wyrzucić warstwę dostępu do danych (tj. LinqToSql -> NHibernate) lub członek zespołu może bez pracy nad jakimkolwiek kodem w innym projekcie. Minusem może być to, że mogą wszystko wysadzić ...