0

カスタム プロパティを持つ SharePoint Web パーツを作成するためのベスト プラクティスを確認しようとしています。私はこれを完全に間違った方法で行っている可能性があるため、背景を詳しく説明します。

私は 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 属性を追加しました。これは、Web経由で正常に機能します。

ただし、SharePoint デザイナーでページを開こうとすると、文字列表現から ChartSettings (および DataTable) を作成できないと不平を言います。これは、設定が文字列として公開されているためであることがわかりました。明らかに、シリアル化を抑制することができる DataTable です。

最終的に私の質問は、設定をクラスに移動する正しいアプローチに従っているかということです。または、すべての設定を Web パーツに残す必要がありますか (多くのシリーズ設定を異なる配列に保持するのは面倒です)、またはまったく異なるアプローチがありますか? あなたの提案をサポートするための参考文献 (MSDN など) を教えていただければ幸いです。

4

1 に答える 1

1

私の個人的な経験（そして一部の人は同意しないかもしれません）は、WebPartを可能な限り薄く保つことでした。Webパーツは、構成、エラー処理とロギング、トレースなどの点で扱いにくいようです。開発の大部分をlocalhost：8080のWS（WebService / WCF）に入れる方がはるかに簡単であることがわかりました。Webパーツのコードは単純です。WSを呼び出して、すべての作業を実行させます。localhostは常に見つけやすいため、Webパーツの構成は簡単になりました。WS/WCFの開発ツールは非常に強力です。WS / WCFでは、構成、デバッグ、エラー処理、ロギング、トレースがすべてはるかに簡単です。さらに良いことに、WSレイヤーを呼び出し/テストするための簡単なジグ（Winform / Webform）を作成します。このアーキテクチャでは、開発ツールが最も強力な場所にコードを配置します。これは、MVCパターンの背後にある理論的根拠に似ています。

于 2012-09-21T16:31:53.870 に答える