current community

your communities

more stack exchange communities

Stack Exchange
tour help
Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 5 down vote favorite
1

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

share|improve this question
3  
Why would create utility classes in any type of project? Why is MVC singled out in your question? –  Oded♦ Sep 10 '13 at 12:19
    
Well I was wondering about MVC because it in a way forces structure. And as far as utility, I was under the impression everyone used them :) If I have an email sender code, and I split it into it's separate class to work with various parts of the system, isn't that a utility class or am I confused? I thought utility classes were once reusable in any program that aren't tied into the code –  user60812 Sep 10 '13 at 12:28
    
I would personally consider email sending a service, abstracted by say the interface IUserNotificationSender or so.. with proper error handling, smtp config etc that doesn't really fit in a utility function... –  Max Sep 10 '13 at 12:30
    
@Max so what would be considered a utility function? I'm trying to understand, as it seems to me I'm very confused –  user60812 Sep 10 '13 at 12:36
    
Well, a proper utility function in my mind is a very small function with a very defined scope and no external dependencies... Such as a function to remove whitespace, or trim a string, or get the nth element of a collection... –  Max Sep 10 '13 at 12:42

3 Answers 3

up vote 6 down vote accepted

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.

share|improve this answer
    
Hi MainMa, so if I understand correctly it's proper to still make a say background class with all the piping, and then abstract it with an interface, and pass the interface to the function instead of straight calling from the class as in your first snippet. –  user60812 Sep 10 '13 at 12:39
1  
@user60812: in short, read about IoC. It would be difficult to explain the whole subject in a simple comment. –  MainMa Sep 10 '13 at 12:44
up vote 2 down vote

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.

Personnaly, 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.

share|improve this answer
up vote 1 down vote

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.