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。できません。それが壊れている理由です。

質問は、例が正しくない場合でも有効です。Mainaによって与えられた答えは、非常に特定のコンテキストでは完璧であり、私にとってはそうではありませんが、「ユーティリティ」クラスの適切なコンテキストです。

個人的には、Helpers拡張機能など、どこからでも呼び出される単純な関数を格納するフォルダーを作成します。この場合、はい、静的です。

今、より良い方法があれば、喜んで学びますが、これまでのところ：

• 拡張機能に問題はありません。
• 特定のフォルダにグループ化しても問題はありません。

現在、拡張機能は単なる構文上の砂糖であり、古典的な機能である可能性もあります。

以前に与えられた答えはどれも実際の質問に対応していません。user60812は、MVCプロジェクト内のどこにユーティリティクラスを配置するかを尋ねました。誰もが特異な例に耳を傾け、手元の質問以外のすべてについて怒鳴りました。

@ user60812、あなたが望む抽象化のレベルに応じて、私は：

• A）フォルダーを作成し、そのフォルダー内にユーティリティクラスを作成します
• B）ユーティリティクラスを保持するプロジェクトを作成します（アセンブリの再利用が必要であると想定）。
• C）ユーティリティをサービスアーキテクチャに外挿して呼び出します

同様の質問へのリンクと、より良い回答があります。

私見では

ユーティリティ用の静的クラスを作成しないでください。ほとんどの場合、静力学は悪いです。マネージャーとも呼ばないでください。どのような作業をしている場合でも、論理的な名前空間に配置する必要があります。

例えば：

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

電子メールアドレス、件名、本文は別の懸念事項であるため、そのためのクラス構造が必要になりEmail emailます。そのため、上記の例で使用したのはなぜですか。