Namespace and class name guidelines

Question

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

How would you structure the following:

EventService.cs
EventServiceUtils.cs
EventServiceValidators.cs
EventServiceCoordinator.cs

etc...

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)
Services.EventService.Validators.DateValidator.cs
Services.EventService.Validators.ParticipantValidator.cs
Services.EventService.Coordinators.ParticipantCoordinator.cs
Services.EventService.ExtensionMethods.Extensions.cs

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.

Answer 1

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)
Services.Events.EventExtensions.cs
Services.Events.ParticipantCoordinator.cs
Services.Validators.DateValidator.cs
Services.Validators.ParticipantValidator.cs

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.

Answer 2

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.

Answer 3

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!