30

What are some best practices for where you should have helper classes in a .NET project? Referring to classes separate from business layer stuff, but presentation and app stuff like appSetting config managers and other code that would sometimes be module specific or sometimes be used throughout the app.

John Saunders
  • 160,644
  • 26
  • 247
  • 397
spaghetticowboy
  • 708
  • 1
  • 8
  • 22
  • Could you elaborate on what you mean by 'helper method,' perhaps with a couple of concrete examples? – Jeff Sternal Jul 29 '10 at 20:15
  • @jeff Pretty much any reusable code. I usualy always have a business layer project seperate from the presentation layer that covers all the functionality of the logical workflow items. But for all the stuff like config setting wrappers and actual helper classes that like build requests, digest query stings, or do common functions on controls im too lazy to extend... that that sorta stuff. I just would like to know what is the preferred way of handling all that. – spaghetticowboy Jul 30 '10 at 13:37

6 Answers6

28

I always allow things like this to be pretty fluid. That said:

  1. I test "helper" classes the same as any other class. This makes them tend to not be static.
  2. I may start by creating these helpers as individual methods when needed. As I find they are needed in more than one class, I'll move them into their own class or a "Utilities" class in the same project.
  3. If I find they are needed in more than one project, then I move them higher up in the "hierarchy": from project to solution, from solution to subsystem, from subsystem to application, from application to library or framework, etc.
John Saunders
  • 160,644
  • 26
  • 247
  • 397
3

I tend to do a combination of what Randolpho and Ben do: I use static helper classes in a "Utilities" folder in a Utilities namespace. Better file organization, keeps the rest of the application namespace clear.

monkeymindllc
  • 1,411
  • 2
  • 9
  • 12
2

I tend to put them in a utils namespace. Either in the mainproject namespace if they are pretty general e.g. MyProject.Utils.MyHelperClass, or if they are more specific then a sub namespace MyProject.CRM.Utils.MyCRMHelperClass.

Ben Robinson
  • 21,601
  • 5
  • 62
  • 79
2

I almost always have a MyProject.Core class library in my solution where I put things like that.

Edit: I might have answered a "bigger" question.

In a single project it all depends on the size of the project. The Microsoft Design Guidelines talks about that you shouldn't create a namespace if you have less then five(correct me if I'm wrong about this number) types within it.

Jesper Palm
  • 7,170
  • 31
  • 36
1

Most of us just throw them in a "Helpers" folder.

Depending on the helper, you might want to mark the methods virtual so you can mock it if necessary. That or bind to an interface it implements, but if you only have one concrete per interface it might be overkill.

Unless the helper methods are pure calculation with no external dependences, under no circumstances should they be static.

Even then, reconsider.

Randolpho
  • 55,384
  • 17
  • 145
  • 179
  • 2
    @Randolpho, what are your reasons for not having simple helper methods as static? What about extension methods? They are typically helpers but are required to be static... – Wallace Breza Jul 29 '10 at 19:19
  • 2
    @Nate Boss: because if your static helper method has an external dependency, you are tightly bound to that dependency when you use the static method. You cant mock it, making your code more difficult to test and maintain. – Randolpho Jul 29 '10 at 20:26
  • @Wallace Breza: Extension methods are perfectly fine if they fall in the category of being pure calculation. – Randolpho Jul 29 '10 at 20:27
  • 1
    I fully understand the limitations on testing staic methods. I was more wondering about the "even then, reconsider" bit... – Nate Jul 29 '10 at 21:02
  • 1
    @Nate: It's one of those rules that's a guideline thing. The guideline is "don't use static methods". If you think a static method does the trick, maybe consider a mockable singleton instead. – Randolpho Jul 30 '10 at 03:46
  • @Nate thank you Nate - what do you mean by: "you are tightly bound to that dependency when you use the static method. You cant mock it" in your above comment. I'm new to these best practices and i'm creating a static class with methods in it to use when necessary. any advice much appreciated. – BenKoshy Jun 13 '16 at 22:55
1

We put such classes in an assembly called Common for example intended to be referenced by all projects which need it except of cases when helper need to use some buisness objects or core objects.

Eugene Cheverda
  • 8,760
  • 2
  • 33
  • 18