Classes utilitaires dans MVC - ASP.NET

Je me demandais donc aujourd'hui, où mettriez-vous des classes utilitaires dans une application ASP.NET MVC? Par classes utilitaires, j'entends des classes qui peuvent être statiques et qui sont juste utilisées pour exécuter une fonction. Comme une classe pour envoyer un e-mail qui prend comme argument l'adresse e-mail, l'objet et le corps.
Je suppose que la création d'un dossier et d'un espace de noms séparés serait peut-être suffisant, mais je voulais obtenir l'avis de tout le monde

Non. Et votre propre exemple est parfait pour montrer pourquoi.

Vous voulez envoyer des e-mails, non? Vous créez donc quelque part une classe statique CommunicationUtilitiesavec une statique SendEmail(). Vous utilisez cette méthode d'une classe qui fait un tas de choses, par exemple réinitialise le mot de passe d'un utilisateur et lui envoie un nouveau par e-mail. Parfait.

Maintenant, que se passe-t-il si vous voulez faire un test unitaire de votre classe? Vous ne pouvez pas, car chaque fois que vous voulez tester la méthode qui réinitialise le mot de passe, cela change la base de données (qui ne convient pas pour un test unitaire), et envoie en outre un e-mail (ce qui est encore pire).

Vous avez peut-être lu sur Inversion of Control, qui a l'avantage de faciliter les tests unitaires. Des articles sur l'IoC vous expliqueront qu'au lieu de faire quelque chose comme:

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

tu fais:

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

ce qui permet d'utiliser des moquettes et des talons.

Essayez d'appliquer l'IoC à votre CommunicationUtilities. Bon, tu ne peux pas. Voilà pourquoi il est cassé.

La question est valable, même si l'exemple donné ne l'est pas. La réponse donnée par Maina est parfaite, dans un contexte très spécifique, qui n'est pas pour moi, le bon contexte pour lesdites classes "utilitaires" .

Personnellement, je crée un dossier Helpersdans lequel je mets des fonctions simples à appeler de n'importe où, comme des extensions, auquel cas, oui, elles sont statiques.

Maintenant, s'il y a une meilleure façon, je serai heureux d'apprendre, mais jusqu'à présent:

• Je ne vois rien de mal avec les extensions.
• Je ne vois rien de mal à les regrouper dans un dossier spécifique.

Maintenant, une extension est juste du sucre syntaxique, elle pourrait aussi bien être une fonction classique.

Aucune des réponses précédemment fournies ne répond à la question réelle. user60812 a simplement demandé où placer une classe utilitaire à l'intérieur d'un projet MVC. Tout le monde a écouté l'exemple singulier et a déclamé tout sauf la question à portée de main.

@ user60812, selon le niveau d'abstraction souhaité, je:

• A) Créez un dossier et créez la classe utilitaire dans ce dossier
• B) Créer un projet pour contenir les classes d'utilité (en supposant le désir de réutilisation de l'assemblage).
• C) Extrapolez vos utilitaires dans une architecture de service et appelez-les

Voici un lien vers une question similaire avec de meilleures réponses.

A mon humble avis

Ne créez pas de classes statiques pour les utilitaires. La statique est mauvaise dans la plupart des cas. Ne les appelez pas non plus managers. Quoi que vous travailliez, il doit être placé dans un espace de noms logique.

Par exemple:

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

L'adresse e-mail, le sujet et le corps sont une préoccupation distincte, donc j'aurais une structure de classe pour cela, d'où la raison pour laquelle j'ai utilisé l' Email emailexemple ci-dessus.