Classi di utilità in MVC - ASP.NET

Quindi oggi mi chiedevo, dove avresti messo le classi di utilità in un'app ASP.NET MVC? Per classi di utilità intendo classi che possono essere statiche e vengono utilizzate solo per eseguire una funzione. Come una classe per inviare un'e-mail che contenga indirizzo e-mail, oggetto e corpo come argomenti.
Suppongo che forse creare una cartella separata e lo spazio dei nomi sarebbe abbastanza buono, ma volevo ottenere le opinioni di tutti

Non E il tuo esempio è perfetto per mostrare perché no.

Vuoi inviare e-mail, vero? Quindi crei da qualche parte una classe statica CommunicationUtilitiescon al suo interno una statica SendEmail(). Si utilizza questo metodo da una classe che fa un sacco di cose, ad esempio reimposta la password di un utente e gli invia una nuova via e-mail. Perfetto.

Ora, cosa succede se vuoi testare l'unità della tua classe? Non puoi, perché ogni volta che vuoi testare il metodo che reimposta la password, cambia il database (che non è adatto per un test unitario) e inoltre invia un'e-mail (che è anche peggio).

Potresti aver letto di Inversion of Control, che ha il vantaggio di semplificare i test unitari. Gli articoli su IoC spiegheranno che invece di fare qualcosa del tipo:

void ResetPassword(UserIdentifier userId)
{
    ...
    new MailSender().SendPasswordReset(userMail, newPassword);
}

tu fai:

void ResetPassword(IMailSender sender, UserIdentifier userId)
{
    ...
    sender.SendPasswordReset(userMail, newPassword);
}

che permette di usare beffe e tronconi.

Prova ad applicare IoC al tuo CommunicationUtilities. Giusto, non puoi. Ecco perché è rotto.

La domanda è valida, anche se l'esempio fornito non lo è. La risposta data da Maina è perfetta, in un contesto molto specifico, che non è per me, il contesto adeguato per le suddette classi di "utilità" .

Personalmente, creo una cartella Helpersin cui inserisco semplici funzioni da chiamare ovunque, come le estensioni, nel qual caso sì, sono statiche.

Ora, se c'è un modo migliore, sarò felice di imparare, ma finora:

• Non vedo nulla di sbagliato nelle estensioni.
• Non vedo nulla di male nel raggrupparli in una cartella specifica.

Ora, un'estensione è solo zucchero sintattico, potrebbe anche essere una funzione classica.

Nessuna delle risposte fornite in precedenza risponde alla domanda effettiva. user60812 ha semplicemente chiesto dove si collocherebbe una classe di utilità all'interno di un progetto MVC. Tutti sostenevano l'esempio singolare e si lamentavano di tutto tranne che della domanda in corso.

@ user60812, a seconda del livello di astrazione che desideri, vorrei:

• A) Creare una cartella e creare la classe di utilità all'interno di quella cartella
• B) Creare un progetto per contenere le classi di utilità (presupponendo il desiderio di riutilizzo dell'assemblaggio).
• C) Estrapolare le tue utility in un'architettura di servizio e chiamarle

Ecco un link a una domanda simile con risposte migliori.

A parer mio

Non creare classi statiche per le utility. La statica è cattiva nella maggior parte dei casi. Non chiamarli nemmeno manager. Qualunque cosa tu stia lavorando, dovrebbe essere collocata in uno spazio dei nomi logico.

Per esempio:

namespace Application.Notifications.Email
{
   public interface ISendEmailCommand
   {
      void Execute(Email email);
   }
}

L'indirizzo e-mail, l'oggetto e il corpo sono una preoccupazione separata, quindi avrei una struttura di classe per questo, quindi perché ho usato Email emailnell'esempio sopra.