Business Logic Layer in MVC Application

Questa sembra una decisione eminentemente ragionevole per me. MVC è un modello di presentazione, pertanto le operazioni di logica aziendale e persistenza non hanno posto nel livello dell'interfaccia utente dell'applicazione.

Idealmente un modello MVC sono solo i dati che si presentano per essere resi dalla vista. Questo non è necessariamente lo stesso di un'entità di dominio equivalente: ad esempio, il modello potrebbe dover essere taggato con attributi di convalida dell'interfaccia utente, potrebbe contenere valori per più selezioni o contenere dati trasformati per la visualizzazione come date, valori di valuta. o traduzioni linguistiche. Per questo motivo, è opportuno rendere l'M in MVC distinto dalle entità aziendali e mappare da entità a modelli nella logica del controller. Un'azione del controller non dovrebbe realmente fare nulla di più complicato che effettuare chiamate al livello della logica di business sottostante e effettuare il marshalling dei dati restituiti nei modelli per il rendering.

Se per modello si intende il modello di dominio, allora quello è il luogo in cui deve risiedere la logica aziendale. Se lo estrai da qualsiasi logica aziendale, ottieni quello che viene comunemente definito "modello di dominio anemico" (vedi www.martinfowler.com /bliki/AnemicDomainModel.html )
Il succo è: la tua azienda ha la sua percezione di un particolare dominio aziendale. Ha determinati termini per le entità, prescrive determinati comportamenti alle entità e le interazioni tra di loro. Il modo migliore per modellare qualcosa del genere è quello di creare effettivamente classi di entità di dominio con comportamento sia statale sia (business). Non creando tutti i tipi di servizi che assorbono i comportamenti che normalmente fanno parte di un'entità di dominio.

Se il modello è un semplice recupero e salvataggio nel DB, non è necessaria una classe modello separata. Sarà un overhead ..

Nel caso tu stia manipolando i tuoi dati e formando una rappresentazione personalizzata della tua classe da mostrare sulla View, ha perfettamente senso seguire il tuo approccio. Inoltre, se in futuro ti aspetti che il tuo Modello venga riempito da fonti diverse, l'approccio sarà un caso perfetto ...

Dipende totalmente dal design della tua applicazione

Come già detto, MVC è solo un modello di presentazione e non c'è nulla di sbagliato nell'avere un livello aziendale. Tuttavia, non dovresti chiamare quel livello direttamente dal Controller, poiché dovrebbero essere molto sottili e senza alcuna logica.

Ci sono in realtà più schemi che puoi, vede il Pattern3 menzionato qui si adatta ai tuoi requisiti.

Certamente un Active Record è un ottimo inizio, ma per quanto riguarda la logica di business per l'integrità (ad es., aggiungi un ordine - che influisce sul saldo del cliente). Vorrei fare attenzione a metterlo nel modello client , poiché non è esposto come servizio per il riutilizzo da parte di altri client, altri computer e così via. Consiglierei di architettare questo in un livello intermedio o database, come ho sostenuto qui .