我们一共花费了大量的时间思考的 SharePoint 解决方案 — 如何创建它们, 使用哪个工具, 当他们无法部署时，会发生什么, 计时器作业, 作用域, 等. 我们花太多时间思考很容易忘记我们需要以及收回他们的前期位. 缩回解决方案也可能是更困难, 从概念设计的角度, 比将它们部署. 部署基本上是食谱件. 通常, 安装功能, 也许有一些数据加载到列表功能接收器, 那种事. 不过, 缩回是潜在的更复杂.
给定的解决方案可能会创建这些工件:
- 内容类型
- 列表定义
- 站点定义
- 列表中的数据
- 甚至接收机
- InfoPath 表单
列表中亮起.
虽然很显然重要设计解决方案的正确实例化这些文物, 它是同样重要的是考虑更新和删除案例. 如果您的解决方案创建新列表，并使用填充该列表数据, 收回该解决方案时，会发生什么? 在某些情况下, 应删除列表. 在其他情况下, 应该留给历史目的不变. 您的业务要求将您引导到正确的决定.
与此帮助, 创建一个矩阵，其中列出了您的解决方案部署到 SharePoint 的每个工件. 列出每个工件的三列, 一个用于创建, 更新和删除. 每个案例, 确定该操作正确结果.
这种分析，显然最好是之前到 SharePoint 场过部署解决方案. 不过, 像吸烟, 开始做正确的事情是永远不会太迟. 创建矩阵和发展计划，以解决缺少的更新/删除场景. 它可能是一个难的问题解决, 但至少你会把解决该问题的一个框.
</结束>
跟我在 Twitter 上 http://www.twitter.com/pagalvin
Technorati 标签: SharePoint 发展
@no 名称
这就是功能接收器类是什么. 您编写自定义代码来处理究竟要重写的方法中的对象模型内您自定义的功能接收器. 请参阅 MSDN 文章 在这里.
Hope that helps 🙂
@Paul
在 SharePoint 用户组演示文稿，因为这几个月就连这篇文章, 如在讨论了这几个月 SPUG, 这真的是创建可靠的 SharePoint 功能的核心问题.
-约翰 · 折弯机
nickelcode.com (博客)