Question

我正在尝试确定创建具有自定义属性的SharePoint WebPart的最佳做法。我将详细介绍背景，因为我可能会以完全错误的方式执行此操作。

我采用了DevExpress图表，其中包含大量设置。然后我决定公开其中的一些设置，最后得到一个看似如下的WebPart：

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;
   }
}

我需要在此Web部件上添加整个加载更多设置，一些是字符串的单个项目，以及与系列相对应的其他项目（例如，绑定值，图表类型）。所以我将设置从WebPart移开，最后得到了类似于以下内容的内容：

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; }
}

我创建了我的设置类Serializable，并在我的Web部件上的Property上添加了Personalizable属性。这可以通过网络正常工作。

如果我尝试在SharePoint设计器中打开页面，但它会抱怨它无法从字符串表示形式创建ChartSettings（和DataTable）。我了解到这是因为设置是以字符串形式公开的。显然我可以通过DataTable来抑制。

的序列化

我的问题最终是，我是否遵循正确的方法，将设置移到课堂上？或者我应该将我的webpart上的所有设置都保留下来（在不同阵列中保留大量系列设置会很麻烦），还是有完全不同的方法？如果你能指出我支持你的建议（例如MSDN），那么非常感谢。

Answer 1

我的个人经历（有些人可能不同意）一直是让WebPart保持尽可能薄。 WebParts似乎很尴尬，例如：配置，错误处理和日志记录，跟踪等。我发现将大部分开发放入localhost：8080上的WS（WebService / WCF）要容易得多。 webpart中的代码很简单：调用WS并让它完成所有工作。现在，webpart中的配置很简单，因为localhost总是很容易找到。 WS / WCF的开发工具非常强大。在WS / WCF中，配置，调试，错误处理，日志记录，跟踪都更加简单。更好的是，我制作了一个简单的jig（Winform / Webform）来调用/测试我的WS层。使用此体系结构，您可以将代码放在开发工具最强的位置。它类似于MVC模式背后的基本原理。

SharePoint Web部件自定义设置 - 最佳实践

1 个答案: