0

我试图确定创建具有自定义属性的 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; }
}

我使我的设置类可序列化，并在我的 Web 部件的属性上添加了一个 Personalizable 属性。这可以通过网络正常工作。

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

我的问题最终是，我是否遵循正确的方法，将设置转移到课程中？或者我应该将所有设置保留在我的 webpart 上（将大量系列设置保存在不同的数组中会很麻烦），还是有完全不同的方法？如果您可以向我指出任何支持您的建议的参考资料（例如 MSDN），那将不胜感激。

4

1 回答 1

1

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

于 2012-09-21T16:31:53.870 回答