Dienstprogrammklassen in MVC - ASP.NET

Ich habe mich heute gefragt, wo Sie Dienstprogrammklassen in eine ASP.NET MVC-App einfügen würden. Mit Utility-Klassen meine ich Klassen, die statisch sein können und nur zum Ausführen einer Funktion verwendet werden. Wie eine Klasse zum Senden einer E-Mail, die E-Mail-Adresse, Betreff und Text als Argumente verwendet.
Ich würde annehmen, dass das Erstellen eines separaten Ordners und Namespaces vielleicht gut genug wäre, aber ich wollte alle Meinungen einholen

Das tust du nicht. Und Ihr eigenes Beispiel ist perfekt, um zu zeigen, warum nicht.

Sie möchten E-Mails verschicken, oder? Sie erstellen also irgendwo eine statische Klasse CommunicationUtilitiesmit einer darin enthaltenen statischen SendEmail(). Sie verwenden diese Methode aus einer Klasse, die eine Reihe von Aufgaben ausführt, z. B. das Kennwort eines Benutzers zurücksetzt und ihm eine neue per E-Mail sendet. Perfekt.

Was passiert nun, wenn Sie Ihre Klasse einem Unit-Test unterziehen möchten? Dies ist nicht möglich, da jedes Mal, wenn Sie die Methode testen möchten, mit der das Kennwort zurückgesetzt wird, die Datenbank geändert wird (was nicht für einen Komponententest geeignet ist) und außerdem eine E-Mail gesendet wird (was noch schlimmer ist).

Möglicherweise haben Sie etwas über Inversion of Control gelesen, was das Testen von Einheiten erleichtert. Artikel über IoC erklären Ihnen, dass Sie nicht etwa Folgendes tun müssen:

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

Sie machen:

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

was erlaubt, Mocks und Stubs zu verwenden.

Versuchen Sie, IoC auf Ihren anzuwenden CommunicationUtilities. Richtig, das kannst du nicht. Deshalb ist es kaputt.

Die Frage ist gültig, auch wenn das angegebene Beispiel nicht zutrifft. Die Antwort von Maina ist perfekt, in einem sehr spezifischen Kontext, der für mich nicht der richtige Kontext für diese "Utility" -Klassen ist.

Persönlich erstelle ich einen Ordner, Helpersin dem ich einfache Funktionen ablege, die von überall aus aufgerufen werden können, z. B. Erweiterungen. In diesem Fall sind sie statisch.

Wenn es einen besseren Weg gibt, werde ich mich freuen zu lernen, aber soweit:

• Ich sehe nichts falsch mit Extensions.
• Ich sehe nichts falsch daran, sie in einem bestimmten Ordner zu gruppieren.

Nun, eine Erweiterung ist nur syntaktischer Zucker, es könnte auch eine klassische Funktion sein.

Keine der zuvor gegebenen Antworten befasst sich mit der eigentlichen Frage. user60812 fragte einfach, wo man eine Utility-Klasse innerhalb eines MVC-Projekts platzieren würde. Alle hielten an dem einzigartigen Beispiel fest und schwärmten über alles außer der vorliegenden Frage.

@ user60812, abhängig von der gewünschten Abstraktionsebene würde ich:

• A) Erstellen Sie einen Ordner und erstellen Sie die Utility-Klasse in diesem Ordner
• B) Erstellen Sie ein Projekt, in dem die Dienstprogrammklassen gespeichert werden (vorausgesetzt, Sie möchten die Assembly erneut verwenden).
• C) Extrapolieren Sie Ihre Dienstprogramme in eine Dienstarchitektur und rufen Sie sie an

Hier ist ein Link zu einer ähnlichen Frage mit besseren Antworten.

meiner bescheidenen Meinung nach

Erstellen Sie keine statischen Klassen für Dienstprogramme. Die Statik ist in den meisten Fällen schlecht. Nennen Sie sie auch nicht Manager. Was auch immer Sie gerade bearbeiten, es sollte in einem logischen Namespace abgelegt werden.

Beispielsweise:

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

E-Mail-Adresse, Betreff und Text sind ein separates Anliegen, daher hätte ich eine Klassenstruktur dafür, weshalb ich Email emailim obigen Beispiel verwendet habe .