Корисні класи в MVC - ASP.NET

Тож мені було цікаво сьогодні, куди б ви розмістили утилітні класи в додатку ASP.NET MVC? Під класами утиліти я маю на увазі класи, які можуть бути статичними і просто використовуються для виконання функції. Як клас для надсилання електронного листа, який бере аргументи електронної пошти, тему та тіло.
Я б припустив, що, можливо, створення окремої папки та простору імен було б досить добре, але хотів отримати думку всіх

Ви цього не робите. І ваш власний приклад є ідеальним, щоб показати, чому ні.

Ви хочете надсилати електронні листи, правда? Так ви створюєте десь статичний клас CommunicationUtilitiesіз статикою SendEmail()в ньому. Ви використовуєте цей метод з якогось класу, який робить купу матеріалів, наприклад, скидає пароль користувача та надсилає йому новий електронною поштою. Ідеально.

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

Ви, можливо, читали про Інверсію управління, яка має перевагу у спрощенні тестування одиниць. Статті про 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) Створіть папку та створіть клас утиліти у цій папці
• B) Створіть проект для проведення класів утиліти (припускаючи бажання повторного використання збірки).
• C) Екстраполюйте свої утиліти в архітектуру сервісу та викликайте їх

Ось посилання на подібне запитання з кращими відповідями.

ІМХО

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

Наприклад:

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

Адреса, тема та адреса електронної пошти - це окрема проблема, тому я маю для цього структуру класів, отже, чому я використовував Email emailу прикладі вище.