Dove sono le regole aziendali in MVC

Question

Ora che tutti parlano di MVC, noto che le regole aziendali non sono state affrontate. Ai vecchi tempi dell'architettura a 3 livelli, le regole aziendali erano nel livello intermedio. Dove cadono nel nuovo MVC?

Answer 1

A prima vista, direi che appartengono al modello. La Voce MVC su Wikipedia sembra concordare: " In MVC, il modello rappresenta le informazioni (i dati) dell'applicazione e le regole aziendali utilizzate per manipolare i dati " ;. Dopotutto, per "regole aziendali" intendiamo gli algoritmi funzionali e la logica che codificano il dominio in cui è coinvolta la tua applicazione, al contrario della logica relativa all'input / output. Questa logica di base aziendale non cambia - o non dovrebbe - cambiare in base a ciò che viene visualizzato all'utente (che è il dominio della vista) o all'input dell'utente (che viene ricevuto principalmente dal controller).

Nella mia esperienza, porre questo tipo di domande è stato molto rivelatore durante il processo di sviluppo del software: abbiamo trovato un gran numero di cose che sono state considerate "regole aziendali" da alcune persone, ma si sono rivelate qualcos'altro. Se non è una vera regola aziendale, potrebbe non appartenere al modello.

Answer 2

Il motivo per cui non vedi mai l'indirizzo MVC " Business Rules " è che MVC in generale è un modello di presentazione. Si concentra su come strutturare la tua applicazione. Il Modello, ad esempio, può essere pensato come un modello di presentazione. Il modello dell'applicazione, che viene quindi visualizzato nella vista.

Tuttavia, per creare il modello di presentazione, in genere è necessario passare ai modelli di dominio in cui risiede tutta la logica aziendale. A quel punto, MVC non stabilisce dove vive fisicamente quel codice. È su un altro livello? A MVC non importa.

Answer 3

Le regole aziendali sono sempre presenti nel modello. Il modello è il bit che è possibile ripristinare con un'interfaccia utente completamente diversa. La vista ovviamente dipende completamente dalle scelte dell'interfaccia utente e il controller deve prendere i dati dal modello e dire alla vista di renderli.

Mettere la logica di business nella vista è male perché lega la struttura alla presentazione.

Mettere la logica di business nel controller è male perché divide il dominio aziendale tra i dati persistenti dal modello e le regole nel controller.

Answer 4

Una citazione da un Wikipedia Articolo :

MVC viene spesso visualizzato nelle applicazioni Web, in cui la vista è la pagina HTML effettiva e il controller è il codice che raccoglie dati dinamici e genera il contenuto all'interno dell'HTML. Infine, il modello è rappresentato dal contenuto effettivo, generalmente archiviato in un database o in nodi XML, e dalle regole aziendali che trasformano quel contenuto in base alle azioni dell'utente.

Answer 5

C'è qualche motivo per cui non puoi mescolare MVC e Ntier? La nostra applicazione fa proprio questo. I nostri controller vengono utilizzati per la convalida dei dati e decidono quali chiamate di livello aziendale effettuare.

OurApp.Web - Progetto Asp.net MVC
OurApp.Business - Libreria di livelli aziendali
OurApp.DataAccess - Libreria livello dati
OurApp.Entities: in pratica tutti i "modelli" condivisi da tutti i livelli

Answer 6

Le regole aziendali dovrebbero essere nel modello, NON nel controller. Il controller e la vista fanno parte del livello di presentazione.

Il modello rappresenta le entità e le funzionalità del dominio.

Il controller è semplicemente un gestore per ricevere input e richieste da parte dell'utente, eseguire azioni nel / sul modello e mapparlo su viste nel layer di presentazione. Il controller non è nemmeno solo un mediatore, la vista OR controller può agire sul modello.

Answer 7

Questa è una domanda postata in precedenza, ma mi piace che un repository di regole sia completamente indipendente da qualsiasi parte di un'applicazione. Più applicazioni, più implementazioni di un livello aziendale, dovrebbero essere in grado di accedere a un rendering statico di un repository di regole di business. Semplici decisioni di separazione come questa fanno una migrazione dal desktop - > web, ad esempio, banale.

Nella mia architettura, Visualizza - > Modello - > Controller - > Livello aziendale - > Il repository delle regole, ovvero il controller accede ai dati grossolani presentati dal livello / livello aziendale, li alimenta al modello che li massaggia in una forma presentabile e la vista li visualizza passivamente. Il livello aziendale, riutilizzabile in qualsiasi formato di presentazione, avrà regole esplicite e accesso a un sottosistema con regole implicite. In base alla progettazione, ogni componente ignora i dettagli di un componente sopra di esso.

Answer 8

Penso che il problema sia una questione di definizione. Mi sembra che la logica per presentare le schermate nell'ordine necessario sia un problema del controller e ho visto alcuni progetti che utilizzano un motore di regole per determinare l'ordine e ciò che è richiesto input dall'utente. Questo non è lo stesso delle regole delle regole aziendali.

Answer 9

Ragazzi, avete torto che le regole aziendali vivano all'interno del controller e non nel modello ...