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.

I'm having problems naming my classes and services correctly when utils and other help classes are involved.

How would you structure the following:



I have multiple services with the same needs as the above service. One thought is to separate all of this into a suitable namespace, making it look something like this:

Services.EventService.EventService.cs //(the actual service)

and so on. Every namespace is of course a separate folder. But this doesn't feel 100%, since there are probably more DateValidators in the other services, which can easily lead to an unwanted reference.

And also the Services.EventService.EventService.cs includes the class name in the namespace, which is no good either. You could use Services.Event.EventService.cs, but there is of course already an entity with that name.

This is the domain model.

share|improve this question

migrated from codereview.stackexchange.com Sep 7 '11 at 19:48

This question came from our site for peer programmer code reviews.

"I have multiple services with the same needs as the above service." Does this mean that multiple services use the above code, or that multiple services need to provide their own version following the same pattern? –  Nathanael Sep 7 '11 at 17:21
That they provide their own version of the same pattern –  Mattias Sep 7 '11 at 19:21

3 Answers 3

up vote 5 down vote accepted

I think the single biggest thing you could do to improve your namespacing here is to remove Service from your EventService namespace. I'd also adjust the namespaces to be more like this:

Services.Events.EventService.cs //(the actual service)

I still think that could use some improvement though.

I used to like namespaces, but nowadays I think less is more. Deeply nesting your namespaces can make your code too verbose, and breaking things down to far reduces your ability for inheritance. In your code for example, a DateValidator class could easily be used elsewhere, so it shouldn't have many namespaces above it, since services other than the EventService can now take advantage of a DateValidator class. The same applies to the extension methods. There's no time (that I can see) where you'd need to see all your extension methods at the same time, therefore it makes more sense to group it with the thing that it relates to. In this case, EventExtensions probably links to your EventService, so logically they should sit together in my opinion.

share|improve this answer
The project is too large not to break it down to a certain level. The DateValidator under the event namespace only handles event-specific cases, and thus cannot be used elsewhere. I do like Services. Events .EventService. How could i not think of that. I think its time for some refactoring! –  Mattias Sep 13 '11 at 5:43
@Mattias - That's fair. As far as I can see, namespacing (beyond the basic guidelines such as those that Saeed mentioned below) is pretty much just a matter of taste. –  Karl Nicoll Sep 13 '11 at 8:47

Why don't you read General Naming Guidelines and Namespace Naming Guidelines from Microsoft to follow a universal pattern?

I think the formula <Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>] just works fine.

share|improve this answer
Its a good pattern. Thanks –  Mattias Sep 13 '11 at 5:39

Proper namespace design will consider both logical and physical design.

Although the original rationale for namespaces was mostly to prevent name clashes between object and method names, it has become an important element in overall solution architecture and design. Not only do you want your conceptual hierarchy and logical design to make sense, you probably also want your code to be tidily packaged in well designed and easily reusable libraries that can be easily bundled into other projects and products later. That is perhaps more the desired outcome of good physical design.

Look at the .NET Framework and how units of related functionality are given to you in reasonably sized assemblies. You can drop in a reference and a using statement and suddenly you have relevant functionality available without having to drag in any number of kitchen sinks. This is because the .NET Framework's physical design—including intelligent namespacing—has packaged logically related code in physically related deployable units. By creating an excellent mapping between namespaces and assemblies, the architects and developers of Microsoft's .NET framework have made your work significantly easier (of course some may argue otherwise, but I'm rather happy with what they did).

Namespaceing in C# is rather arbitrary, really. You can put namespaces in the oddest places, in assemblies far removed from each other. Any helpful discipline in this area is really your personal contribution to a well organized software product. I would not dare to advise you of exactly what to do in each case. What I hope to accomplish, in this answer, is to get you to think about physical design as well as logical design when you define your namespaces. The more you keep things logically related and deployably (physically) bundled the easier things will be later, both for you and for others who might need to deal with your code some day.

So, please do think about how your code will be packaged in assemblies and components when you resolve your namespacing issues!

share|improve this answer
Thats some very good points John! Thank you. –  Mattias Sep 13 '11 at 5:45

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.