Klasy narzędzi w MVC - ASP.NET

Zastanawiałem się dzisiaj, gdzie umieściłbyś klasy narzędzi w aplikacji ASP.NET MVC? Przez klasy użytkowe rozumiem klasy, które mogą być statyczne i służą do wykonywania funkcji. Jak klasa, która wysyła wiadomość e-mail, która przyjmuje jako argument argument adres, temat i treść.
Zakładam, że może utworzenie osobnego folderu i przestrzeni nazw byłoby wystarczająco dobre, ale chciałem uzyskać opinie wszystkich

Ty nie. A twój własny przykład jest idealny, aby pokazać, dlaczego nie.

Chcesz wysyłać e-maile, prawda? Więc tworzysz gdzieś klasę statyczną CommunicationUtilitiesze statyczną zawartością SendEmail(). Używasz tej metody z klasy, która robi mnóstwo rzeczy, na przykład resetuje hasło użytkownika i wysyła mu nowe przez e-mail. Doskonały.

Co się stanie, jeśli chcesz przetestować jednostkę w klasie? Nie możesz, ponieważ za każdym razem, gdy chcesz przetestować metodę, która resetuje hasło, zmienia bazę danych (co nie nadaje się do testu jednostkowego), a ponadto wysyła wiadomość e-mail (co jest jeszcze gorsze).

Być może przeczytałeś o Inwersji Kontroli, która ma tę zaletę, że ułatwia testowanie jednostek. Artykuły o IoC wyjaśniają, że zamiast robić coś takiego:

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

ty robisz:

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

co pozwala używać makiet i odcinków.

Spróbuj zastosować IoC do swojego CommunicationUtilities. Racja, nie możesz. Dlatego jest zepsuty.

Pytanie jest prawidłowe, nawet jeśli podany przykład nie jest. Odpowiedź udzielona przez Mainę jest idealna, w bardzo specyficznym kontekście, który nie jest dla mnie odpowiednim kontekstem dla wspomnianych klas „użytkowych” .

Osobiście tworzę folder, Helpersw którym umieszczam proste funkcje do wywoływania z dowolnego miejsca, takie jak rozszerzenia, w którym to przypadku tak, są one statyczne.

Teraz, jeśli istnieje lepszy sposób, chętnie się nauczę, ale jak dotąd:

• Nie widzę nic złego w rozszerzeniach.
• Nie widzę nic złego w grupowaniu ich w określonym folderze.

Teraz rozszerzenie to tylko cukier składniowy, równie dobrze może być klasyczną funkcją.

Żadna z podanych wcześniej odpowiedzi nie dotyczy rzeczywistego pytania. user60812 po prostu zapytał, gdzie należy umieścić klasę użyteczności w projekcie MVC. Wszyscy podeszli do pojedynczego przykładu i narzekali na wszystko oprócz pytania.

@ user60812, w zależności od pożądanego poziomu abstrakcji:

• A) Utwórz folder i utwórz klasę narzędzia w tym folderze
• B) Stwórz projekt do przechowywania klas użytkowych (zakładając chęć ponownego użycia zestawu).
• C) Ekstrapoluj swoje narzędzia do architektury usług i zawołaj do nich

Oto link do podobnego pytania z lepszymi odpowiedziami.

moim zdaniem

Nie twórz klas statycznych dla narzędzi. W większości przypadków statyka jest zła. Nie nazywaj ich także menedżerami. Cokolwiek nad tym pracujesz, powinno być umieszczone w logicznej przestrzeni nazw.

Na przykład:

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

Adres e-mail, temat i treść to osobna kwestia, dlatego miałbym do tego strukturę klas, dlatego użyłem tego Email emailw powyższym przykładzie.