Lo scopo di un livello di servizio e ASP.NET MVC 2

Question

Nel tentativo di comprendere MVC 2 e tentare di ottenere la mia azienda ad adottarlo come una valida piattaforma per lo sviluppo futuro, ho fatto un sacco di lettura ultimamente. Avendo lavorato con ASP.NET abbastanza esclusivamente per gli ultimi anni, ho avuto un po 'di ritardo da recuperare.

Al momento, ho capito il Pattern Repository, modelli, controllori, le annotazioni di dati, ecc Ma c'è una cosa che mi impedisce di abbastanza completamente comprensione per iniziare a lavorare su un'applicazione di riferimento.

Il primo è il modello di servizio di livello. Ho letto molti post e domande qui su Stack Overflow, ma io ancora non comprendere appieno lo scopo di questo modello. Ho guardato l'intera serie di video in MVCCentral sulla Golf Tracker Applicazione e visto anche il codice demo ha postato e sembra a me come il livello di servizio è solo un altro involucro intorno al modello repository che non esegue alcun lavoro a tutti.

Inoltre ho letto questo post: http: //www.asp. net / Imparare / MVC / tutorial-38-cs.aspx e sembrava un po 'di rispondere alla mia domanda, tuttavia, se si sta utilizzando le annotazioni di dati per eseguire la convalida, questo sembra inutile.

Ho cercato le dimostrazioni, i messaggi, ecc, ma non riesco a trovare nulla che semplicemente spiega il motivo e mi dà una prova convincente di usarlo.

Qualcuno può fornire me con un 2 ° grado (ok, forse 5 ° grado), la ragione per utilizzare questo modello, quello che avrei perso se non lo faccio, e che cosa ci guadagno se lo faccio?

Answer 1

In un pattern MVC si ha responsabilità separata tra i 3 giocatori:. Model, View Controller e

Il Modello è responsabile per fare la roba di business, la vista presenta i risultati del business (che fornisce anche l'input per l'attività da parte dell'utente), mentre il controller si comporta come il collante tra il modello e la vista, che separa il funzionamento interno di ogni dall'altro.

Il Modello di solito è sostenuta da un database in modo da avere alcuni DAO di accesso a questo. La vostra azienda fa un po 'di ... beh ... di business e negozi o recupera i dati nel / dal database.

Ma che coordina le DAO? Il controller? No! Il modello dovrebbe.

Inserisci il livello di servizio. Il livello di servizio fornirà alto servizio al controller e gestirà altri giocatori (di livello inferiore) (DAO, altri servizi, ecc) dietro le quinte. Esso contiene la logica di business della vostra applicazione.

Che cosa succede se non si usa?

Si dovrà mettere la logica di business da qualche parte e la vittima è di solito il controller.

Se il controller è web centric che dovrà ricevere input e fornire una risposta come HTTP richieste, risposte. Ma cosa succede se voglio chiamare mia app (e ottenere l'accesso al business fornisce) da un'applicazione Windows che comunica con RPC o qualche altra cosa? Cosa poi?

Bene, si dovrà riscrivere il controller e fare l'agnostico cliente logica. Ma con il livello di servizio che hai già. Yyou non hanno bisogno di riscrivere le cose.

Il livello di servizio fornisce comunicazione con DTOs, non vincolati ad un'implementazione specifica controllore. Se il controllore (non importa che tipo di controller) fornisce i dati appropriati (nessun mater la fonte) il vostro livello di servizio farà il suo dovere fornire un servizio al chiamante e nascondendo il chiamante da tutte le responsabilità del logica di business coinvolti.

Answer 2

Devo dire che sono d'accordo con DPB con quanto sopra, lo strato di involucro cioè servizio è riutilizzabile, mockable, sono attualmente in fase di includere questo strato dentro la mia app ... qui sono alcuni dei problemi / esigenze I sto riflettendo su (molto rapidamente: p) che potrebbe essere fuori aiuto per youeself ...
1. più portali (ad esempio Blogger portale, portale clienti, portale interno), che saranno necessarie per accedere da molti utenti diversi. Tutti devono essere separati applicazioni ASP.NET MVC (un requisito importante)
2. Nell'ambito delle applicazioni stesse alcune chiamate al database sarà simile, i metodi e il modo in cui i dati vengono trattati dallo strato repository. Senza dubbio alcuni controller da ogni modulo / portale farà esattamente o una versione sovraccarico della stessa chiamata, quindi una eventuale necessità di un livello di servizio (codice a interfacce) che vi quindi compilare in un progetto di classe separato.
3. Se creo un progetto di classe separata per il mio livello di servizio posso avere bisogno di fare lo stesso per il Data Layer o combinarlo con il livello di servizio e mantenere il modello di distanza dal progetto Web stesso. Almeno in questo modo come il mio progetto cresce posso buttare via lo strato di accesso ai dati (vale a dire LinqToSql -> NHibernate), o un membro lattina squadra senza lavorare su alcun codice in qualsiasi altro progetto. Il rovescio della medaglia potrebbe essere che potrebbero far saltare tutto in su lol ...