CODEWITHSUNDEEP
c#interfacemacros
Varun
Varun

Reputation: 59

C# interfaces and macro constant alternatives

I'm creating a RESTful service using a C# WCF project and have a question about interfaces and macro constant alternatives.

I have a bunch of WebGet decorations which look like this (highly simplified):

public interface IRestSerivce
{
    [OperationContract]
    [WebGet( UriTemplate = "{a}/{b}/{c}/someName01?param={val}" )]
    string Handler01( .. );

    [OperationContract]
    [WebGet( UriTemplate = "{a}/{b}/{c}/someName02?param={val}" )]
    string Handler02( .. );

    [OperationContract]
    [WebGet( UriTemplate = "{a}/{b}/{c}/someName03?param={val}" )]
    string Handler03( .. );
}

and so forth.

Having used C extensively in the past, I would normally have created a macro constant for the common text "{a}/{b}/{c}" so that it isn't repeated everywhere.

Usual C# alternatives such as private readonly string or private const string would not work in this scenario due to the kind of string in question (it is in a decoration) and in any case, the interface cannot have members.

Is there any way to make it such that a future change in the API (say {b} turns into {b1}/{b2}) doesn't require me to make the changes everywhere?

Solutions to this I've found so far look like what's mentioned here: http://social.msdn.microsoft.com/Forums/en-US/csharplanguage/thread/71e8d202-b249-49bb-a85d-b0ef8207463d/ but I don't think that applies here because I believe it is too late to modify a decoration string in the implementation of the interface.

Upvotes: 1

Views: 899

Answers (1)

Alexei Levenkov
Alexei Levenkov

Reputation: 100537

const string should be fine. You can't have it inside an interface, but can refer to the constant in other classes.

static class Prefixes
{
    public const string Basic = "{a}/{b}/{c}";
}

public interface IRestSerivce
{
    [OperationContract]
    [WebGet( UriTemplate = Prefixes.Basic + "/someName01?param={val}" )]
    string Handler01( .. );
}

Using const string is ok as the whole value is computed at compile time and in the resulting assembly there is only the combined string in the attribute.

Upvotes: 4

Related Questions