Geeks With Blogs
Brian Biales because blogging is just the easiest way to remember things

When I generated my first SCSF "Hello World" client application to see what it was all about, I noticed that there was a folder called "Constants" and in each folder there were generated four source modules: CommandNames.cs, EventTopicNames.cs, UIExtensionSiteNames.cs, and WorkspaceNames.cs

This folder was found in the Infrastructure.Interface module, but also in each module "FooModule" I had the factory generate, it would create this folder in the two VS projects it would create, one being the "FooModule" project, the other being the "FooModule.Interface" project.

At first glance, this was a little confusing.  But as I studied it, it became a lot clearer, even elegant and convenient... 

First of all, for those that don't know, the SCSF framework keeps track of many of its parts in dictionaries that are indexed by a string.  These Constants source modules specify classes that let you easily create constants you can use in the code to reference these strings.  This helps you find typos at compile time, rather than at run time, using these classes is highly recommended.  

But in which place should you define any particular constant?  Well, that depends on who needs to know about it.  For any of these indexes, if you want a "global" name, you should define it in "Infrastructure.Interface" project.  For instance, say you need a "well known" event topic name that the shell and all the application modules should know about.  Define it once in the Infrastructure.Interface project, as this module is referenced by all the modules in the project automatically when generated by the factory.  All these modules will "automatically" gain access to these constants.  Here's how...

There is a slight difference in each of the source files in the Constants folders.  Under the Infrastructure.Interface, EventTopicNames.cs file, for instance, a class is declared as such:

namespace MyRootNS.Infrastructure.Interface.Constants{
Constants for event topic names.
   public class
Event fired to tell the shell to update the status panel
      public const string StatusUpdate = "StatusUpdate"

Here you see one event topic that all modules should know about.  

Now if you look in project "FooModule.Interface", this is where you would define constants such as Event Topics that are defined by the FooModule, but other modules that know a little bit about this one may want to either subscribe to or fire.  So the "FooModule.Interface" project is a good place to put this.  Other modules can reference this Interface project, which should be pretty static, even as developers work on the actual implementation of the foo module in the "FooModule" project.

Under the FooModule.Interface project, in the Constants folder, in the EventTopicNames.cs file, for instance, a class is declared as such:

namespace MyRootNS.FooModule.Interface.Constants
   /// <summary>
   /// Constants for event topic names.
   /// </summary>
   public class EventTopicNames : MyRootNS.Infrastructure.Interface.Constants.EventTopicNames

Notice that this class, also called EventTopicNames, inherits from the Infrastructure.Interface.Constants.EventTopicNames class above.  So any static constant defined there is automatically a static member of this class. 

Finally, in the FooModule Project itself is another Constants folder with a source file called EventTopicNames.cs. This one defines a class named EventTopicNames but this time it inherits from the MyRootNS.FooModule.Interface.Constants.EventTopicNames class.  So it automatically contains all the static members defined in the previous two classes...

So now for the elegant part...  When you are adding code to either the module's controller class (in ModuleController.cs) or in the presenter for one of the Views you add to your module (in YourViewNamePresenter.cs) in the Foo Module, you would add the following "using" clause at the top of the source (this should really be done for you by the factory, but is not in the current release):

using MyRootNS.FooModule.Constants;

So now, while typing your code and you need to reference one of these EventTopicName constants, simply type  EventTopicNames. and Intellisense will present you with all the constants defined in the FooModule implementation project, as well as the more public ones in the FooModule.Interface project, as well as any even more public ones defined by the Infrastructure.Interface project.  They will all be there, you don't have to worry about which source file this particular event topic constant was defined in afterall...

And if you are working in another module, and you include the following line:

using MyRootNS.FooModule.Interface.Constants;

You can reference event topic names defined in the FooModule.Interface project or the shell infrastructure interface, as these are available for public consumption.

Well, I think this is an elegant way of handling these constants.  They are defined in different places based on the scope of their use, but when referencing one of them, you just find it within the list of all the constants you have available to you at your module's particular scope.

Posted on Monday, March 12, 2007 3:49 PM .NET , SCSF - Smart Client Software Factory , C# | Back to top

Comments on this post: CAB/SCSF Constants classes, their hierarchy, and Intellisense

# re: CAB/SCSF Constants classes, their hierarchy, and Intellisense
Requesting Gravatar...
I very good explanation abt constants,where to deleare and why.
Left by suraj on Oct 22, 2009 5:01 AM

Your comment:
 (will show your gravatar)

Copyright © Brian Biales | Powered by: