SharePoint WebPart Custom Settings - Best Practise

Question

I'm trying to ascertain what the best practise is for creating a SharePoint WebPart that has custom properties. I'll detail the background, because I might be doing this in completely the wrong way.

I've taken a DevExpress chart, which has a whole host of settings on there. I then decided to expose some of these settings and ended up with a WebPart that looked like:

public class MyWebPart : WebPart
{
   public DataTable { get; set; }
   public String ConnectionString { get; set; }
   public String Query { get; set; }

   public override void DataBind() 
   {
      UpdateMyTable(ConnectionString, Query);
      this.chartControl.DataSource = this.DataTable;
   }
}

I needed to add a whole load more settings onto this web part, a few single items that are strings, and others that correspond to a series (e.g. Binding values, Chart Type). So I moved the settings off the WebPart and ended up with something more akin to the following:

public class MyWebPart : WebPart
{
   public DataTable { get; set; }
   public ChartSettings { get; set; }

   public override void DataBind() 
   {
      UpdateMyTable(ConnectionString, Query);
      this.chartControl.DataSource = this.DataTable;
   }
}

public ChartSettings
{
    public List<SeriesSettings> Series { get; set; }
}

I made my settings classes Serializable and added a Personalizable attribute on the Property on my web part. This works fine via the web.

If I attempt to open the page in SharePoint designer however it complains that it can't create a ChartSettings (and DataTable) from their String representations. I've learnt that this is because the settings are exposed as Strings. Obviously the DataTable I can suppress the serialization of.

My question ultimately is, am I following the correct approach, moving settings onto a class? Or should I be leaving all the settings on my webpart (which would be messy keeping lots of series settings in different arrays), or is there a completely different approach? If you can point me to any references to support your suggestion (e.g. MSDN) then that would be very much appreciated.

tgolisch tgolisch · Accepted Answer · 2012-09-21T16:31:53

My personal experience (and some may disagree) has been to keep the WebPart as thin as possible. WebParts seem to be awkward for things like: configuration, error handling and logging, tracing, etc. I have found it much easier to put the bulk of my development into a WS (WebService/WCF) on localhost:8080. The code in the webpart is simple: call the WS and let it do all of the work. Config in the webpart is now simple because localhost is always easy to find. Dev tools for WS/WCF are very strong. Config, debugging, error handling, logging, tracing are all much simpler in WS/WCF. Better still, I make a simple jig (Winform/Webform) to call/test my WS layer. With this architecture, you put your code where your dev tools are strongest. It is similar to the rationale behind the MVC pattern.

SharePoint WebPart Custom Settings - Best Practise

1 Answers