So I was wondering today, where would you put utility classes in an ASP.NET MVC app? By utility classes I mean classes that can be static and are just used to perform a function. Like a class to send an email that takes email address , subject, and body as arguments.
I would assume maybe creating a separate folder and namespace would be good enough, but wanted to get everyone opinions
- 401
4 Answers
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.
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.
- 137,583
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
- 117
- 201
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.
- 4,060
- 1
- 22
- 23