Служебные классы в MVC - ASP.NET

Итак, мне было интересно сегодня, где бы вы разместили служебные классы в приложении ASP.NET MVC? Под служебными классами я подразумеваю классы, которые могут быть статическими и просто используются для выполнения функции. Как класс, чтобы отправить электронное письмо, которое принимает адрес электронной почты, тему и тело в качестве аргументов.
Я бы предположил, что, возможно, создание отдельной папки и пространства имен было бы достаточно, но хотел бы узнать мнение каждого.

Вы не И ваш собственный пример является идеальным, чтобы показать, почему нет.

Вы хотите отправлять электронные письма, верно? Таким образом, вы создаете где-то статический класс CommunicationUtilitiesсо статическим SendEmail()в нем. Вы используете этот метод из некоторого класса, который делает кучу вещей, например, сбрасывает пароль пользователя и отправляет ему новый по электронной почте. Отлично.

Что произойдет, если вы захотите провести юнит-тестирование своего класса? Вы не можете, потому что каждый раз, когда вы хотите проверить метод, который сбрасывает пароль, он изменяет базу данных (которая не подходит для модульного теста) и, кроме того, отправляет электронное письмо (что еще хуже).

Возможно, вы читали об Inversion of Control, которая имеет преимущество, облегчая модульное тестирование. Статьи о IoC объяснят вам, что вместо того, чтобы делать что-то вроде:

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

ты сделаешь:

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

что позволяет использовать издевательства и заглушки.

Попробуйте применить IoC к вашему CommunicationUtilities. Точно, ты не можешь. Вот почему это сломано.

Вопрос правильный, даже если приведенный пример - нет. Ответ, данный Майной, идеален в очень специфическом контексте, который не является для меня подходящим контекстом для упомянутых «полезных» классов.

Лично я создаю папку, Helpersв которую помещаю простые функции, которые будут вызываться из любой точки мира, например, расширения, в этом случае, да, они статичны.

Теперь, если есть лучший способ, я буду рад узнать, но пока

• Я не вижу ничего плохого в расширениях.
• Я не вижу ничего плохого в группировании их в определенной папке.

Теперь расширение является просто синтаксическим сахаром, оно также может быть классической функцией.

Ни один из ранее приведенных ответов не относится к актуальному вопросу. user60812 просто спросил, где можно разместить служебный класс внутри проекта MVC. Все послушались единственного примера и побеспокоились обо всем, кроме вопроса.

@ user60812, в зависимости от желаемого уровня абстракции, я бы:

• A) Создайте папку и создайте служебный класс в этой папке.
• Б) Создайте проект для хранения служебных классов (при условии повторного использования сборки).
• C) Экстраполировать ваши утилиты в сервисную архитектуру и вызывать их

Вот ссылка на похожий вопрос с лучшими ответами.

по моему мнению

Не создавайте статические классы для утилит. Статика плохая в большинстве случаев. Не называйте их менеджерами. Над чем бы вы ни работали, оно должно быть помещено в логическое пространство имен.

Например:

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

Адрес электронной почты, тема и текст сообщения - это отдельная задача, поэтому у меня для этого будет структура классов, поэтому я и использовал Email emailпример выше.