Using nested static classes

I'm wondering if any of you use static nested classes? Any opinions or drawbacks?

Here's an example...

Code:

---

public class Constants
{
        internal static class DB
        {
                public static class Params
                {
                        public const string Address1 = "Address1";
                        public const string City = "City";

                        public class Scheduler
                        {
                                public const string Active = "Active";
                                public const string DepartmentID = "DepartmentID";
                        }
                }

                public static class Sprocs
                {
                        public static class Employee
                        {
                                public const string Create = "[dbo].[Employee.Create]";
                                public const string Delete = "[dbo].[Employee.Delete]";
                                public const string Get = "[dbo].[Employee.Get]";
                                public const string GetList = "[dbo].[Employee.GetList]";
                        }
                }

                public static class Connections
                {
                        public static string Facilitator
                        {
                                get { return ConfigurationManager.ConnectionStrings[ "Facilitator" ].ConnectionString; }
                        }
                }
        }
}

---

Usage:

Code:

---

publicEmployee[ ] GetEmployees( Guid companyID, bool includeInactive )
{
  List<Employee> list = newList<Employee>( );

  using( DAL dal = DAL.Create( Constants.DB.Connections.Facilitator ) )
  {
    dal.Open( );

    SqlParamCollection sqlParams = SqlParamCollection.Create( );
    sqlParams.Add( Constants.DB.Params.CompanyID, companyID );
    sqlParams.Add( Constants.DB.Params.IncludeInactive, includeInactive );

    using( SafeDataReader dr = SafeDataReader.Create( dal.ExecuteReader( Constants.DB.Sprocs.Employee.GetList, sqlParams ) ) )
    {
      while( dr.Read( ) )
      {
        list.Add( EmployeeCreator.Create( dr ) );
      }
    }
  }
  return list.ToArray( );
}

---

Comments?
[/SIZE]

Wouldn't you be able to do this more simple with name spaces?

I agree with the above. For starters you could probably nuke the 'public class Constants' part. Secondly, static consts like this "public const string Address1 = "Address1";" are a waste of everyones time. If you really want them, the at least should be private to the class they're located in. What you really want public is methods like:

public IEnumerable<Employee> GetEmployees ();
public void CreateEmployee (Employee e);

That makes sense to expose. It's a task which needs to be done. You can refactor what those methods do a million times and the user of that task doesn't care. They'll still either get a list of employees or create a new employee. But what is the user of your lib going to do with a public const string whose value is the same as a the name of the field? Nothing really... it's a bit pointless :)

Keep in mind that this static class is used in a variety of other classes. The method in which I used them is just on example of one method in one class.

Why would public consts be a waste of time? I hear about making them private to a class, but what about when these constants are used in a variety of classes? For example, CompanyId might be used in a class that returns a list of stores or another class that returns employees. I'm not sure it makes sense to make duplicate CompanyId constants in each class.

This nested class is used within a WCF service, so it's not an exposed library per se. As such, rather than public, internal might be a better choice.

If namespaces are used, would it be appropriate to put each separate class declaration into the same file?

I'm not really against using the static classes. However with the short sample you gave us it doesn't really make sense to use static classes that ONLY contain other static classes and no methods. You might as well use a namespace for that.

The other benefit of using namespaces, as you already pointed out, is that you can place the class declarations in separate files. This allows you to organize the code a little better since you can put your Constants.DB.Sprocs.Employee class in the same area as your Employee class. In the end though, I like the idea of putting the constant strings as a variable name, sure... you can just type out the name but I love intellisense and clean looking code. While the implementation of the static classes may not be ideal the end result is very elegant and easy to read.

Not to mention that having the constant strings turned into variables will help with refactoring your code should you ever need to change the values of those strings.

Everyone, thanks for the feedback.

I've use it one time (more preciselly, I've got it as a legacy) and althought I considere it the best solution, it works and perfectlly meets the needs.