2008年5月11日,星期日

为开发人员介绍SharePoint Config存储

今天,我想介绍一下我最近正在做的事情,如果您是SharePoint开发人员,这可能对您有用。通常,在开发需要编码的SharePoint解决方案时,开发人员会面临如何使用他/她不想“硬编码”为C#或VB.Net代码的值的决定。 SharePoint网站/应用程序/控件的示例值可能是:

'AdministratorEmail'-'bob@somewhere.com'
'SendWorkflowEmails'-'true'

通常,我们避免对这些值进行硬编码,因为如果需要更改该值,则必须重新编译代码,进行测试并重新部署。因此,人们可能会考虑的硬编码替代方案可能是:

  • 将值存储在web.config的appSettings部分中
  • 将值存储在不同的位置,例如功能属性,事件处理程序注册数据等。
  • 将值存储在自定义SQL表中
  • 将值存储在SharePoint列表中

就个人而言,尽管我喜欢将复杂的自定义配置部分存储在web.config中的功能,但我不是appSettings的忠实拥护者。如果需要更改值,则必须使用远程桌面连接到服务器,然后打开并修改文件-如果我位于具有多个前端的服务器场中,则需要为每个服务器重复此操作,并且m还会导致下一个请求变慢,因为应用程序域将卸载以刷新配置。通过其他选项,第二个选项不是很好,因为我们每次都需要重新激活功能/事件接收器注册(甚至更麻烦),尽管第三个选项(使用SQL)可能很好,除非我想要一个前端-最终使修改值变得更容易,在这种情况下,我们需要做一些工作。

因此将配置值存储在SharePoint列表中可能会很好,并且是我解决方案的基础。现在我敢打赌,很多人已经在这样做了-编写一些简单的代码来获取值非常快,这意味着我们避免了硬编码问题。但是,Config Store的“框架”远不止于此-一方面,它经过高度优化,因此您可以确定不会对性能产生负面影响,但是在可以使用的地方和易于使用方面也有一些好处。部署。因此,我希望展示的是,Config Store的功能远不止是“从列表中检索配置值”的简单实现。

详细信息(从Codeplex网站复制)

用于存储配置项目的列表如下所示(注:所示项目是我的示例,您可以添加自己的示例):

ConfigStoreList.jpg
与列表关联的是特殊的内容类型,因此添加新项很容易:

ConfigItemContentType.jpg

..并定义了内容类型,以便所有必填字段均为必填字段:

AddNewConfigItem.jpg

检索值


将值添加到Config Store后,可以按以下方式在代码中检索它(当然,您还需要添加对Config Store程序集的引用和“ using”语句):

string sAdminEmail = ConfigStore.GetValue("MyApplication", "AdminEmail");


请注意,还有一种检索方法 单个查询的值。这避免了执行多个查询的需要,因此出于性能原因,如果您的控件/页面将进行检索,则应使用它 许多 Config Store中的项目-将其视为最佳实践。该代码稍微复杂一些,但是当您仔细考虑时应该会有意义。我们创建一个通用的“ ConfigIdentifiers”列表(ConfigIdentifier指定 类别 名称 该项目的'MyApplication','AdminEmail')并将其传递给'GetMultipleItems()'方法:


List<ConfigIdentifier> configIds = new List<ConfigIdentifier>();

ConfigIdentifier adminEmail = new ConfigIdentifier("MyApplication", "AdminEmail");
ConfigIdentifier sendMails = new ConfigIdentifier("MyApplication", "SendWorkflowEmails");
configIds.Add(adminEmail);
configIds.Add(sendMails);
Dictionary<ConfigIdentifier, string> configItems = ConfigStore.GetMultipleValues(configIds);
string sAdminEmail = configItems[adminEmail];
string sSendMails = configItems[sendMails];

..该方法返回一个包含值的通用词典,我们通过将之前创建的相应ConfigIdentifier传递给索引器来检索每个值。


其他注意事项
  • 所有项目都包装在解决方案/功能中,因此无需手动创建站点列/内容类型/配置存储列表等。还有一个安装脚本,可让您轻松安装解决方案。

  • 配置项被缓存在内存中,因此可能的话 甚至不会 数据库查询!

  • Config Store还设计为在不存在SPContext的地方运行,例如列表事件接收器。在这种情况下,它将在SharePoint Web应用程序的web.config文件中查找值以建立包含Config Store的网站的URL(注意:将Config Store安装到您的网站时,这些web.config密钥会自动添加)。这也意味着它可以在SharePoint应用程序之外使用,例如控制台应用程序。

  • 可以从站点的根网站的默认位置移动配置存储。例如,我创建的站点通常具有隐藏的“配置”网站,因此我将“配置存储”以及其他项目放在这里。 (为此,请从“配置存储列表”模板(在安装过程中添加)创建一个新列表(在所需的任何子站点中),然后修改添加到您的站点的“ ConfigWebName” /“ ConfigListName”键。如果您已经添加了100个不想重新创建的项目,则可以使用我的另一个工具SharePoint Content Deployment Wizard(SharePoint内容部署向导) http://www.codeplex.com/SPDeploymentWizard 移动列表。)

  • 包括所有源代码和解决方案/功能文件,因此,如果您要更改任何内容,可以

  • 安装说明位于下载的readme.txt中


概要

希望您可能同意Config Store超出了“在列表中存储配置值”的简单实现。对我而言,关键方面是缓存以及整个解决方案已“联结”的事实,因此,作为一项功能很容易快速而可靠地进行部署。许多组织可能正处于其SharePoint代码库逐渐成熟的阶段,并且可能基于“核心API”的基础-Config Store可以在这种工具箱中提供有用的功能。


您可以从以下位置下载Config Store框架和所有源代码 www.codeplex.com/SPConfigStore.

13条评论:

理查德·爱德华兹 说过...

克里斯,这看起来很棒。感谢您的贡献!

未知 说过...

克里斯,你好

如果将Sharepoint安装为服务器场该怎么办。由于配置存储在内存中,因此必须在每个服务器上输入列表值,在这种情况下,SPPersistedObject将是更好的选择。

问候,
Jagannath

克里斯·奥'Brien 说过...

您好Jagannath,

有趣的想法,以及过去曾向我提出过​​的建议。但是,在我看来,配置存储的要点之一是它是SharePoint列表!尝试暂时不要将其视为开发人员,这具有重要的优势。无论在哪里实现,用于缓存列表项的服务器之间的内存量都不是问题。

有效的讨论。

谢谢,

克里斯。

匿名 said...

嗨!

好主意,我对使用web.config也有同样的担心。我认为您的解决方案非常出色,因为它可以被许多站点/应用程序使用。我对其他功能有建议。具有“安排”设置更改的功能将是很棒的。例如,在某些情况下,beeing能够应用配置更改以使其在特定日期的午夜生效将非常有帮助。

做得好!

克里斯·奥'Brien 说过...

尼克

有趣的主意:-)

克里斯。

匿名 said...

克里斯,你好
辛苦了当然,许多人会发现配置存储很有用。这是我遇到的一些困难。

自述文件中有一些错字。几个appsetting键不太正确。

将“ ApplyWebConfigModifications”的Feature属性设置为“ True”,我必须在featureReceiver中更改几行,以便条目将自身删除:


configMod.Name = string.Format(“ add [@name ='{0}']”,sModificationName);

变成...

configMod.Name = string.Format(“ add [@key ='{0}'] [@ value ='{1}']”,sKey,sValue);


configMod.Name = string.Format(“ add [@name ='{0}']”,sModificationName);

变成...

configMod.Name = string.Format(“ add [@expressionPrefix ='{0}'] [@ type ='{1}']”,sPrefix,sType);

如果我错了,请原谅-我是新手。但这似乎已经解决了我的问题。

克里斯·奥'Brien 说过...

嗨乔治,

非常感谢,非常感谢。但是,我确定在上载到Codeplex的最新版本中已修复了web.config密钥删除问题。在2.0.0.0版本或1.0.0.0版本中找到问题了吗?

干杯,

克里斯。

大卫·巴罗 说过...

克里斯,您好,我回应您的观点,非常棒。

但是,(而且我不确定这是否是George报告的确切问题,但我没有尝试进行修改);我还想报告一下,我似乎遇到了一个问题,即使在feature.xml中将ApplyWebConfigModifications标志设置为True时,如果停用该功能,FeatureDeactivating代码也不会从web.config文件中删除您的条目。因此,在重新激活该功能时(例如,在开发过程中,反复激活和停用该功能时),这些条目会一遍又一遍地写入web.config文件。仅供参考。无论如何,都是非常有用的工具,感谢您的使用。 -戴维·鲍罗

克里斯·奥'Brien 说过...

嗨,戴夫,

感谢您的肯定。就这个问题而言,我本人肯定看过它,但是我确实对该版本2.0.0.0进行了一些更改,并确保它们测试正常。

您是否知道从Codeplex下载的版本是2.0.0.0?

谢谢,

克里斯。

大卫·巴罗 说过...

克里斯,你好

我只是点击了您博客上的链接(上面);在CodePlex上说:

更新:2009年4月20日上载了2.1.0.0版,并提供了重要修复-有关发行说明,请参见2.1.0.0版页面

克里斯·奥'Brien 说过...

戴夫

感谢您回到我这里-我将在本周重新测试并在此处发布。

干杯,

克里斯。

克里斯·奥'Brien 说过...

@戴夫

不幸的是,您是对的-认为这是最新版本中的回归错误。现在已在2.1.0.1版中修复 http://spconfigstore.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=27194.

对于那个很抱歉!感谢您指出:-)

干杯,

克里斯。

匿名 said...

出色的工作,您的头脑定在正确的位置,使共享点更接近于Web应用程序的可行替代方案

不错的工作!!!