Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

If I'm doing a website, I end up with folders like "Controllers, Views, Models, Extensions, and Helpers". If I'm doing a DLL library I end up with folders reflecting the namespaces of my classes. If I write a desktop app, I end up with "Presentation and models" where models is subdivided further by namespaces.

My question is, where is a common place to put classes that aren't necessarily part of your logic or model?

For instance, if I find some code to convert XML to some arbitrary format, I usually put it in a static class and drop it in a folder called utilities. That's easy, but when I get into something that borders on domain logic that converts from XML into a domain specific language, where do I draw the line?

That's a pretty specific case, but I run into tons of these where I'm torn on putting it in the Utilities folder, the helpers folder etc. These are all folders I use, but hopefully the concept is clear, I just don't know how to organize my code when it isn't clear domain logic.

share|improve this question
Have a look at extension methods if your using .net 4. They are great and help avoid using loads of static methods – Tom Squires Dec 29 '11 at 22:44

If I have some code that needs to be used by domain logic, but isn't actually domain logic, I'll usually create a "Utility" folder inside the folder which houses the actual domain logic. That way the code is separate, but what it should be used with is immediately obvious. This creates a new namespace at the level I plan on using the utility classes which makes it easy to see when something is a utility versus domain logic (utilities will be prefixed by a "Utility." or otherwise.

share|improve this answer

Anything not specific to your application should be separated into different projects (i.e. assemblies) and referenced from projects that require these assemblies. These projects will likely contain generic code that doesn't use any specific domain or business logic (e.g. sorting functions). These projects may be used by other applications at some point, so it's important that they are separate and can be referenced when needed.

share|improve this answer

Leave them in a namespace that uses the given functionality. "Utils" should refer to something abstract and reusable.

share|improve this answer

Your Answer


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.