Dove inserire la manipolazione dei dati e il codice di logica aziendale nell'applicazione ASP.NET MVC?

Question

Dopo aver visto i campioni dall'applicazione Kona di Rob Conery, vedo che sta usando due cose con IoC - ISession, dove ha codice di livello dati e Servizi, dove ha alcune logiche di business aggiuntive che dobbiamo eseguire quando manipolano i dati nel datastore . Ad esempio, potremmo non solo aggiungere un record al DB, ma anche modificare le proprietà di un altro record, aumentare alcuni conteggi, riprendere qualcosa, ecc. Abbiamo bisogno di mettere quel codice aggiuntivo da qualche parte e lo inserisce in quei servizi.

Ad esempio, ha un CustomerService che manipola i clienti. Ciò richiede l'invio dell'istanza di ISession al CustomerService, in modo che CustomerService possa utilizzarlo per accedere all'archivio dati.

Ora un altro modo di farlo sarebbe quello di inserire quel codice aggiuntivo nella classe Customer stessa e inviare l'ISession (o IRepository, qualunque terminologia usiamo) a quella classe. E non avere alcun servizio. Tipicamente, le classi cliente, ordine, prodotto, ecc. Sono classi modello, in modo da risultare in classi di modelli grandi/pesanti.

La mia domanda è: quale soluzione è migliore? Finora non ne avevo la necessità, perché avevo la maggior parte del codice nei controller, ma ora con la crescita della mia applicazione, devo prendere una decisione su questo e pulire i controller.

Attualmente ho: - controller grassi con la logica di business in esso, - repository molto atomiche, - modelli molto pulite e ViewModel.

Devo passare a: - controllori sottili, - repository con più codice, - modelli con codice di logica di business (in particolare dovrebbero mie classi modello contenere metodi come add(), remove(), per esempio Customer.Remove() ??)

o per - controllori sottili, - repository atomiche, - modelli ancora pulito, - servizi (per incapsulare tutto il resto che non va in nessuna delle precedenti).

Answer 1

Si consiglia di disporre di archivi contenenti operazioni atomiche con classi di modelli e livello di servizio che dipendono da tali archivi per definire le operazioni aziendali. Il concetto di AOP può essere utilizzato per avviare automaticamente una transazione SQL all'inizio di ogni operazione aziendale e eseguire il commit alla fine o il rollback in caso di eccezione.

Infine, i controller utilizzeranno tali classi di servizio e convertiranno i modelli di dominio e i modelli di visualizzazione.