Refactoring di una base di codice MVC esistente per rimuovere la logica aziendale e l'accesso ai dati dai controller

Il prodotto che ho ereditato ha la seguente composizione:

• Sito Web MVC in cui i controller effettuano chiamate ai repository per ottenere, inserire e aggiornare gli oggetti recuperati

definito in:

• Livello di accesso ai dati scritto utilizzando Linq2SQL

Questo significa che attualmente il controller per l'azione / Account / Aggiungi eseguirà il seguente pseudo-codice:

• Ottieni l'utente corrente
• new () un oggetto AccountItem
• Imposta i campi UserId, AccountItemTypeId e Value sull'oggetto Account
• Ottieni un'istanza del deposito
• Chiama il metodo InsertOnSubmit (AccountItem item) di repositorys

• Chiama il metodo SubmitChanges () di repositorys

• nuovo () un elemento EmailQueue

• Imposta le proprietà appropriate sull'elemento EmailQueue (su, oggetto, corpo, ecc.) in base all'elemento dell'account inserito
• Ottieni un'istanza del deposito
• Chiama il metodo InsertOnSubmit (metodo EmailQueue) di repositorys
• Chiama il metodo repositorys SubmitChanges ()

Ho già fatto un primo passaggio attraverso il codebase e l'ho iniettato, usando Castle Windsor, il repository in (effettivamente iniettando un'istanza di un tipo che implementa IRepositoryResolver che ha un metodo chiamato GetRepository<T> in modo da poter disaccoppiare i controllori dai repository dipendenti da Linq2SQL. Ho anche iniziato a scrivere test unitari, basati sul comportamento corrente dei controller (per garantire che quando apporto ulteriori modifiche riesca a identificare quando ottengo un errore orribile) ma è tangenitalmente domanda reale.

Ho identificato molti luoghi in cui le azioni del controllore eseguono azioni identiche contro vari repository, come ottenere un totale di% di utenti pari a% co_de per tutti Value e sto considerando di estrarre tutta questa logica comune in un livello aziendale / servizio. La mia domanda è: la seguente struttura dovrebbe essere considerata "migliore pratica":

• AccountItem : fornisce un metodo AccountService (più altri come AddAccountItem )
• GetAccountValue : fornisce un metodo EmailService

Devo refactoring il controller in modo che lo faccia:

accountServiceInstance.AddAccountItem(userToCredit, userCrediting, AccountItemType.Bonus, 300);
emailServiceInstance.AddEmailToQueue(userToEmail, EmailType.AccountCreditBonus);

Oppure, se il mio AddEmailToQueue prende un AccountService come dipendenza (che è soddisfatto da Castle Windsor) ed è responsabilità di EmailService chiamare AccountService ?