You don’t. And your own example is a perfect one to show why not.

You want to send emails, right? So you create somewhere a static class CommunicationUtilities with a static SendEmail() in it. You use this method from some class which does a bunch of stuff, , for example resets the password of a user and sends him a new one by email. Perfect.

Now, what happens if you want to unit-test your class? You can’t, because every time you want to test the method which resets the password, it changes the database (which is not suitable for a unit test), and moreover sends an email (which is even worse).

You may have read about Inversion of Control, which has a benefit of making unit testing easier. Articles about IoC will explain you that instead of doing something like:

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

you do:

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

which allows to use mocks and stubs.

Try to apply IoC to your CommunicationUtilities. Right, you can’t. That’s why it’s broken.

The question is a valid one, even if the example given is not. The answer given by Maina is perfect, in a very specific context, which is not to me, the proper context for said “utility” classes.

Personally, I create a folder Helpers in which I put simple functions to be called from about anywhere, like extensions, in which case, yes, they are static.

Now, if there is a better way, I will be glad to learn, but so far:

• I see nothing wrong with Extensions.
• I see nothing wrong with grouping them in a specific Folder.

Now, an extension is just syntaxic sugar, it could as well be a classic function.

None of the answers previously given address the actual question. user60812 simply asked where one would place a utility class inside of an MVC project. Everyone harked on the singular example and ranted about everything except the question at hand.

@user60812, depending on the level of abstraction you want, I would:

• A) Create a folder and create the utility class within that folder
• B) Create a project to hold the utility classes (assuming the desire for assembly reuse).
• C) Extrapolate your utilities into a service architecture and call out to them

Here is a link to a similar question with better answers.

IMHO

Don’t create static classes for utilities. Statics are bad in most cases. Don’t call them managers either. Whatever it is you are working on, it should be placed in a logical namespace.

For example:

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

Email address, subject and body is a separate concern, therefore I would have a class structure for that, hence why I’ve used Email email in example above.