La logica aziendale deve essere inserita nel modello e dovremmo mirare a modelli modelli e skinny controllori .

Come punto di partenza, dovremmo iniziare dalla logica del controller. Ad esempio: durante l'aggiornamento , il tuo controller dovrebbe indirizzare il tuo codice al metodo / servizio che consegna le tue modifiche al modello.

Nel modello, possiamo facilmente creare classi helper / service in cui l'applicazione regole o calcoli aziendali può essere convalidata.

Un riepilogo concettuale

• Il controller è per la logica dell'applicazione. La logica specifica di come la tua applicazione vuole interagire con il "dominio della conoscenza" appartiene.

• Il modello è per la logica indipendente dall'applicazione . Questa logica dovrebbe essere valida in tutte le possibili applicazioni del "dominio della conoscenza" a cui appartiene.

• Pertanto, è logico inserire tutte le regole aziendali nel modello.

Come sempre, dipende dalla complessità del progetto.

Nelle applicazioni banali, in cui la complessità del modello di dominio è relativamente piccola, puoi inserire la logica nei modelli e chiamarla un giorno.

Tuttavia, per applicazioni non banali con modelli complessi e molte regole aziendali, è meglio separare le cose un po 'di più.

Se si inserisce la logica aziendale che coinvolge più di un modello in un modello, si introduce un accoppiamento stretto tra tali modelli. Poiché le applicazioni continuano a crescere, questi modelli tendono a trasformarsi in god models , sapendo troppo. E questo si trasformerà rapidamente in un grande casino che è difficile da testare e mantenere. In tal caso, è utile mettere la logica in un livello separato.

Quando decidi l'astrazione, prendi in considerazione la complessità e gli scopi della tua app ed evita la sovraingegnerizzazione. Per applicazioni banali / di piccole dimensioni, l'introduzione di più livelli di quelli necessari aumenta la complessità anziché ridurla.

Robert Martin (Uncle Bob) ha un buon post sul blog su questo argomento: The Clean Architecture.

Mettere la logica di business all'interno del modello potrebbe sembrare il modo migliore per andare. Il controller riceve una chiamata dall'app Web remota. Il controller sul servizio Web MVC accetta la chiamata e reindirizza l'esecuzione a un metodo in BL. Ora, Business Logic può essere contenuta nel 'Modello', ma può anche essere posizionata in un'altra cartella, ad esempio 'Business Logic' . Quindi non esiste una regola ferrea su dove sarà la logica di business.

Ho utilizzato un servizio web creato su MVC 3.0 e il contenitore della logica aziendale è MVC MODELLO .