SharePoint Web Part & Singletons

Question

I have a sharepoint project where we override search box and some other things. We also have a web part page that responds to the search box. All these components should share single configuration. I thought about creating a singleton, but I am not sure how would that ever get cleaned up / removed from the memory / uninstalled.

Any ideas? Any warnings about using singletons in sharepoint? Also, is there a proper way to share an instance of an object between all these componenets?

Edit: I was thinking about a very simple singleton. Configuration only needs to contain 5-20 strings and a dozen integers at most. No complex objects :)

Answer 1

As long as the objects being managed by your singleton class are thread-safe there shouldn't be an issue.

EXAMPLE:
I have a series of object-calls that were taking a long-time to process (7+ seconds). So, I decided to try using a comet-styled long-polling technique to process them. As such, I host a service (as a static singleton) in a single thread and process requests using asynchronous HttpHandler's...and it works GREAT! And because I'm using the service asynchronously it's highly efficient because the calling thread gets released immediately (upon completion of processing the service completes the callback).

EDIT:
But your problem of a long processing time still exists, so you still (probably) need an asynchronous solution for the initial fetch. Hows this? Why not COMBINE the asych-solution with custom-caching?

For various (accessibility) reasons, I save my appSetting's in the database and use a custom-cache for access thereafter.

EXAMPLE of a Custom Cache:

public enum ConfigurationSection
{
    AppSettings
}

public static class Utility
{
    #region "Common.Configuration.Configurations"

    private static Cache cache = System.Web.HttpRuntime.Cache;

    public static String GetAppSetting(String key)
    {
        return GetConfigurationValue(ConfigurationSection.AppSettings, key);
    }

    public static String GetConfigurationValue(ConfigurationSection section, String key)
    {
        Configurations config = null;

        if (!cache.TryGetItemFromCache<Configurations>(out config))
        {
            config = new Configurations();
            config.List(SNCLavalin.US.Common.Enumerations.ConfigurationSection.AppSettings);
            cache.AddToCache<Configurations>(config, DateTime.Now.AddMinutes(15));
        }

        var result = (from record in config
                      where record.Key == key
                      select record).FirstOrDefault();

        return (result == null) ? null : result.Value;
    }

    #endregion
}

namespace Common.Configuration
{
    public class Configurations : List<Configuration>
    {
        #region CONSTRUCTORS

        public Configurations() : base()
        {
            initialize();
        }
        public Configurations(int capacity) : base(capacity)
        {
            initialize();
        }
        public Configurations(IEnumerable<Configuration> collection) : base(collection)
        {
            initialize();
        }

        #endregion

        #region PROPERTIES & FIELDS

        private Crud _crud; // Db-Access layer

        #endregion

        #region EVENTS
        #endregion

        #region METHODS

        private void initialize()
        {
            _crud = new Crud(Utility.ConnectionName);
        }

        /// <summary>
        /// Lists one-to-many records.
        /// </summary>
        public Configurations List(ConfigurationSection section)
        {
            using (DbCommand dbCommand = _crud.Db.GetStoredProcCommand("spa_LIST_SecConfiguration"))
            {
                _crud.Db.AddInParameter(dbCommand, "@Section", DbType.String, section.ToString());

                _crud.List(dbCommand, PopulateFrom);
            }

            return this;
        }

        public void PopulateFrom(DataTable table)
        {
            this.Clear();

            foreach (DataRow row in table.Rows)
            {
                Configuration instance = new Configuration();
                instance.PopulateFrom(row);
                this.Add(instance);
            }
        }

        #endregion
    }

    public class Configuration
    {
        #region CONSTRUCTORS

        public Configuration()
        {
            initialize();
        }

        #endregion

        #region PROPERTIES & FIELDS

        private Crud _crud;

        public string Section { get; set; }
        public string Key { get; set; }
        public string Value { get; set; }

        #endregion

        #region EVENTS
        #endregion

        #region METHODS

        private void initialize()
        {
            _crud = new Crud(Utility.ConnectionName);
            Clear();
        }

        public void Clear()
        {
            this.Section = "";
            this.Key = "";
            this.Value = "";
        }
        public void PopulateFrom(DataRow row)
        {
            Clear();

            this.Section = row["Section"].ToString();
            this.Key = row["Key"].ToString();
            this.Value = row["Value"].ToString();
        }

        #endregion
    }
}

Answer 2

If your object is simply configuration (loaded once, and stays read only from that point) I'd not worry about it beeing singleton or about if/when it will be garbage collected (object will not be collected unless you set it to null).

In general in server environment (like SharePoint) you want to make sure 2 things about object before thinking about making it singleton:

• technical aspects (mainly thread safety as pointed by Prisoner ZERO, but also how much memory it uses, if it holds critical resources likle files)
• security aspects - it is extremly easy to leak user's information into singleton object and use it by mistake by some other user. It also possible to cache some information in singleton that one user have access to and than retrive by another user that should not have access to such information.

Answer 3

I think you may be over complicating this and falling into the trap of premature optimisation.

You indicate that your object doesn't have anything more than a couple of dozen strings/integers so presumably you're not doing any expensive setup and therefore is there actually anything to be gained going the singleton approach?

Furthermore the real question here is where these strings/integers are going to be stored - if its hardcoded into your class then you can't update it easily so it would be better to store that config somewhere else.

Six Ways to to store settings in SharePoint

But IHMO the best way to do this is following the MSDN SharePoint Guidance Library which uses the Property Bag storage for their implementation of a hierarchical Configuration Manager which allows you to do things like a farm wide setting but overridden for certain site collections/sites etc.

So in conclusion I personally would

• Implement the config object as a simple object reading values from config manager
• Montor/profile and change to a singleton if necessary