Click here to Skip to main content
15,789,698 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
Hi I am working on a project that has the following class:
public class RS
    public enum dtData { TransactionID, TransactionDateTimeStamp, FileToCompress, DirectoryToCompress, CompressedFileName, Action };
    public enum dtTransaction { TransactionID, TransactionDate, CompressedFileName, TransactionSuccessFlag, TransactionErrors };
    public enum dtError { TransactionID, ErrorMessage, InnerException, StackTrace, Data };
    public enum dsTables { Transaction, Data, Error };
    public enum WEBCONFIGXML { UniqueID, TransactionDateTimeStamp, XElement, FirstNode, ConfigFileName, ConfigDirectory, Action }
    public enum Enviornments { Test1, Test2, Test3}

    public enum WEBCONFIGURATORXMLELEMENTS { Variable, Name, Description, value, TemplateDerivable, EnvironmentName }
    public enum WEBCONFIGURATORXML { Environment, Name, FilePrefix }

    public const String ConnectionString = "<Property Name=''ConnectionString'' Value=''|*|ConnectionString_AppDatabase|*||*|ConnectionString_Extension|*|''/>";
    public const String sendQueuePath = "<Property Name=''sendQueuePath'' Value=''|*|SendQueue_Sql|*|''/>";         

What is the best way for me to convert this class to a configurable item and how would I call this new item from within my code? Thanks in advance.

1 solution

By adding properties and fields that actually store data. There is no reason (that I can see) that you are internally defining enumerations, these can all be placed outside of the class in a namespace by themselves.

As it stands right now, your class is just a container (and should be marked static) for some enumerations and some strings.

Maybe it would help if you actually explained what you wanted to store inside of it, and what its purpose is, rather than asking how to make it "configurable".
Share this answer
Sergey Alexandrovich Kryukov 18-Nov-13 17:24pm    
Why do you object against nested types, like enumeration inside class? I think: 1) there is nothing wrong with that; 2) even when it makes no functional difference, it indicates that this inner type (enumeration, in this case) is intended for work with the declaring type, closely related to it; doesn't it has its value? 3) it does not complicate anything.

To me, it looks like quite a reasonable style of designing the code...
Ron Beyer 18-Nov-13 17:37pm    
I'm not against it, as long as it has some reason for being declared inside another class. There are good examples of a good use of this, but they typically revolve around that enumeration or type being used in that class. Thats not the case here, its simply a type that holds other types. Which is why I said that I can't see the reason why they are declared internally. If there is a lot of other missing code then that would explain it, but as it stands I can't see a good reason for defining them like that, in this instance...
Sergey Alexandrovich Kryukov 18-Nov-13 18:34pm    
Okay, I mean the cases when there are no reasons except those I listed above... But I can see your point: this is really the class used to hold some other types together. Well, yes, in such a case just a namespace would do the same, besides, such class should be 1) static, 2) have more appropriate name...
pmcm 19-Nov-13 7:20am    
the aim is to make it easier to manage these items for future changes. Instead of having to update this class and release a new build having this data in an xml file or defined in the app.config would mean only 1 file has tp be updated. I'm not asking for you guys to do this for me but if you could point me in the correct direction with a tutorial or link I can try it and then ask for more help if required.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900