我們一共花費了大量的時間來思考的 SharePoint 解決方案 — 如何創建它們, 要使用哪個工具, 當他們無法部署時，會發生什麼, 計時器作業, 作用域, 等. 我們花太多時間思考很容易忘記我們需要以及收回他們的前期位. 縮回解決方案也可能是更困難, 從概念設計的角度看, 比將它們部署. 部署基本上是食譜件. 通常, 安裝功能, 也許有一些資料載入到一個清單中的功能接收器, 那種事. 不過, 縮回是潛在的更複雜.
給定的解決方案可能會創建像這些工件:
- 內容類型
- 清單定義
- 網站定義
- 清單中的資料
- 甚至接收機
- InfoPath 表單
該清單將亮起.
雖然很顯然重要的是設計的解決方案，正確地具現化這些文物, 它是同樣重要的是考慮更新和刪除案例. 如果您的解決方案創建新清單，並使用填充該清單資料, 收回該解決方案時，會發生什麼? 在某些情況下, 應刪除清單. 在其他情況下, 應該留給歷史目的不變. 您的業務要求將您引導到正確的決定.
與此説明, 創建一個矩陣，其中列出了您的解決方案部署到 SharePoint 的每個工件. 列出每個工件的三列, 一個用於創建, 更新和刪除. 每個案例, 確定該操作的正確結果.
這種分析，顯然最好是之前到 SharePoint 場過部署解決方案. 不過, 像吸煙一樣, 開始做正確的事情是永遠不會太遲. 創建矩陣和發展計畫，以解決缺少的更新/刪除場景. 它可能是一個難的問題解決, 但至少你會放一個框周圍問題.
</結束>
跟我在 Twitter 上 http://www.twitter.com/pagalvin
Technorati 標籤: SharePoint 發展
@no 名稱
這就是功能接收器類為. 您編寫自訂代碼來處理過什麼你想要重寫的方法中的物件模型內您自訂的功能接收器. 請參閱 MSDN 文章： 在這裡.
Hope that helps 🙂
@Paul
在 SharePoint 使用者組的演示文稿，因為這幾個月就連這篇文章, 如在討論了這幾個月 SPUG, 這真的是創建可靠的 SharePoint 功能的核心問題.
-約翰 · 班德
nickelcode.com (博客)