5

Suppose you have this:

namespace Project.Services
{
   public class ClientService
   {
      public IEnumerable<Clients> Query(Project.Models.Builders.ClientQueryBuilder builder)
      {
           //...
      }
   }
}

AFK namespaces help you to organize your project in a miningful way. It provides a context of how the module is supposed to work.

In this case the builder parameter is in Project.Models.Builders namespace and it's being use in Project.Services namespace. Here are 2 different namespace with totally different context working to together.

The question is: Should ClientQueryBuilder class be in the Service namespace?

  • 4
    What about system provided namespaces? System.IO.File, etc. – Dan Pichelman Jun 22 '17 at 19:42
  • 2
    Why don't you just add using Project.Models.Builders;? – Robert Harvey Jun 22 '17 at 20:55
  • 2
    Then no, you shouldn't. You should use the using statement, exactly as the C# creators intended. – Robert Harvey Jun 22 '17 at 21:01
  • 2
    Ask a better question, get a better answer. You asked "should I?" I answered "no." If the coupling of the namespaces bothers you, then find a way to organize them that better suits your sensibilities. – Robert Harvey Jun 22 '17 at 21:04
  • 1
    Per se, there is nothing wrong with using multiple namespace. Sometime it might help find architectural problems (undesirable dependencies) if the dependencies goes in the wrong direction. To enforce proper dependencies, distinct assemblies could be used at appropriate boundaries. – Phil1970 Jun 23 '17 at 13:12
9

Should I move ClientQueryBuilder class to Service namespace?

No. You will end up with one giant namespace.

But I think the flaw in the logic goes deeper. You say that namespaces are a way of organising your project. But I disagree.

Projects are a way of organising your solution.

Namespaces are a way of not duplicating class names across projects.

So here you are referencing the Models project in your Service project. There's nothing wrong with that and it is perfectly reasonable, indeed perhaps normal! for a service to consume objects from a different project as parameters.

However, having said that, given the naming of the class ClientQueryBuilder perhaps Models isn't the best place for it? I'm just going off the class name though not the fact that its in a different namespace.

| improve this answer | |
2

It's going to become hard to communicate across namespaces if you do this everywhere. If you're confident it won't cause ambiguous name conflicts you can do this:

namespace Project.Services
{
   using Project.Models.Builders;

   public class ClientService
   {
      public IEnumerable<Clients> Query(ClientQueryBuilder builder)
      {
           //...
      }
   }
}

Otherwise just do this:

namespace Project.Services
{
   using ClientQueryBuilder = Project.Models.Builders.ClientQueryBuilder;

   public class ClientService
   {
      public IEnumerable<Clients> Query(ClientQueryBuilder builder)
      {
           //...
      }
   }
}

There, now you've "moved" it into the namespace where you need it in without confusing everything that expects it to stay put. This means you are free to organize things based on where people might expect to find them not based on where they happen to be needed.

Some good documentation about this can be found here.

| improve this answer | |
  • surely the original question only excludes the using statement to show that the parameter is from a different namespace? – Ewan Jun 22 '17 at 22:14
0

Should ClientQueryBuilder class be in the Service namespace?

Yes and no and it all depends on how you define a Service and what you want the user to see first. To me, in general, a service is a class that does something useful and not just stores data. If the ClientQueryBuilder is such a thing, that does help to create a ClientQuery then it could be seen as a service.

I mostly use the Services namespace to put types there that are hard to categorize by any other criteria. If I had only one builder I would let it sit in the Services namespace but if I had more of them then I would create another namespace Builders inside the Services namespace and put it there.

namespaces help you to organize your project in a miningful way

Yes, they do. You can use namespaces to hide types that are more special and rarely used directly and put more common types in the main namespace so that it's easier to find and use them.

For example if you have a framework that provides classes for parsing something you would rather not put them in the Parsers namespace so that after you install the package you could use them immediately because they are what this package is all about. On the other hand if some parsers only support your framework/library that it would be better to hide them in the Parsers namespace so that they don't interfere with intellisense because their usage is rather unlikely anyway.

In your case the builder is not just a parameter... it's a tool for creating a query so it has every right to be the part of the services namespace (under the assumption it really is a builder as we know it).

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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