3

My team has a lot of IOC conventions that look something like...

if (type.Namespace == "My.Fun.Namespace")
{
    // do stuff
}

Of course, maintaining this kind of thing becomes brutal after awhile, and we would rather not. The only option I could think of was to store these all in one place, as string constants or something of that nature, but that isn't a lot better... We have been considering making classes that basically serve as namespace identifiers in order to have almost an anchor type to key off of, like, say...

if (type.Namespace == typeof(My.Fun.Namespace.MarkerClass).Namespace)
{
    // do stuff
}

But that just feels weird. So is there another way to solve this one that we just don't know about? If not, has anyone had any luck with the whole marker class concept?

4
  • 1
    This looks an awful lot like a degenerate switch statement. Wouldn't it be better to have a query to see if the object responds to a particular method? Apr 29, 2014 at 22:46
  • 7
    Why do you need to know a type's namespace in order to use IOC?
    – Bernard
    Apr 30, 2014 at 1:17
  • I agree with @BobDalgleish. Backup and take a look at why you need to identify the namespace.
    – DwB
    Apr 30, 2014 at 16:15
  • 1
    To elaborate on @Bernards point, what are you doing inside those if blocks? Perhaps there is a better way to accomplish it than this.
    – Sacrilege
    Apr 30, 2014 at 16:17

1 Answer 1

1

I think your second approach is the best solution. However, I understand that it looks weired to access the namespace by using another class as a reference. Maybe you can maintain a single file with many namespaces only containing a single interface.

namespace My.Fun.NameSpace
{
    interface IContract { }
}
namespace My.Other.NameSpace
{
    interface IContract { }
}

usage:

if (type.Namespace == typeof(My.Fun.Namespace.IContract).Namespace)
{
    // do stuff
}

Another option I could think of is an extension method

namespace System
{
    public static class TypeExtension
    {
        public static bool IsFromFunNameSpace(this Type type)
        {
             return IsFromNameSpace(type, typeof(My.Fun.NameSpace.IContract));
        }

        public static bool IsFromOtherNameSpace(this Type type)
        {
            return IsFromNameSpace(type, typeof(My.Other.NameSpace.IContract));
        }

        private bool IsFromNameSpace(Type type, Type contract)
        {
            type.Namespace == contract.NameSpace;
        }
    }
}

usage:

if (type.IsFromFunNameSpace())
{
    // do stuff
}

Anyway your IOC approach looks weired to me. The ultimate solution (which requires you to have access to the source code) would be to just let a class implement an interface (which can be empty)

public interface IFun { }

public class FunnyClass : IFun { }

usage:

if (typeof(IFun).IsAssignableFrom(type))
{
    // do stuff
}

Now you are not limited to a specific namespace

2
  • return type.Namespace == "My.Fun.Namespace" - would it play nicely with obfuscation? Personally I prefer your first suggestion. It's type-safe. I'd only give it some more meaningful name perhaps. May 9, 2014 at 7:59
  • @KonradMorawski would it play nicely with obfuscation that's a good point, probably not. Anyway you can combine both approaches, I updated the code. May 9, 2014 at 8:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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