Advantages and Disadvantages of using SPPersistedObject over Web.Config files

Well, only a few days back I had a chance to look at SPPersistedObject when I was looking at a source code of a solution in Codeplex. Since then I started feeling that I should have known about it a long time back so that I could have used it in all my previous projects.

If you have not used or even heard about SPPersistedObject kindly have a look at this here which describes on how to use it.

In my previous and current SharePoint projects we always used to store the configuration entries in the Web.Config file of the SharePoint web applications hereafter. And, once the application goes for production we lose our access on the web.config file to the support team which has been giving me a headache all these days because of which I have decided to use SPPersistedObject in my applications. So, I have decided to list out the advantages and disadvantages of using SPPersistedObject.

Let’s go for the advantages first.

Advantages:

  1.  Whenever you change any value in the Web.Config file of the SharePoint application, you need to change it both in both the WFE’s(if at all you have more than one :D) of your farm. Whereas, while using SPPersistedObject this is not the case as the value is going to be stored in the Configuration database.
  2. Whenever you change any value in the Web.Config file of the SharePoint application the App pool of the SharePoint application gets recycled which is not the case while using SPPersistedObject as the changes in the Configuration database is not going to affect the App pool of the application.
  3. When applications using web.config file entries are removed from SharePoint, the web.config file entries of the application remain as such until they are deleted manually. Whereas, a SPPersistedObject can be deleted using SPPersistedObject.Delete() method.
  4. Moreover, so many people might develop applications with respect to your SharePoint site and store their configuration entries in the web.config file which sometimes can become misery when someone else is also using the same configuration entries as you are.
  5. Suppose your SharePoint application has been deactivated and no longer used, the web.config file entries used by that application will always be present unnecessarily unless and until they are deleted manually. Whereas, in the case of SPPersistedObject we can delete the SPPersistedObject object from the configuration database as shown here in the feature deactivation event receiver.
Disadvantages:
  1. When you are going to use SPPersistedObject, then you need to write a separate custom class in order to add and retrieve the config entries. Whereas when you are using web.config, the entries can easily be accessed using Configuration.Appsettings property in System.Configuration namespace.
  2. The custom class written in order to add and retrieve the config entries cannot be reused for all the applications that you are going to develop. You need to write a separate custom class for each application.
  3. This class is not available in Client Object Model. SPPropertyBag can be used in that case.
So, these are the advantages and disadvantages that I have in mind right now. Will update whenever I face something new while I use it and explore SPPersistedObject more.
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s