以SharePoint或Not（作爲應用程序開發的基礎）（vs ASP.NET）

Question

我有一個POV，您應該只在這些條件下使用SharePoint進行應用程序開發。

1）應用程序使用文檔，這些文檔需要某種功能，SharePoint非常好（搜索/索引，與Outlook同步等）。如果您只想要一個文檔存儲桶和一個列表，然後ASP .NET或ASP.NET MVC。

2）應用程序必須使用工作流程或自定義工作流程。沒有工作流再次我會看向ASP.NET或ASP.NET MVC。

3）公司必須願意將至少1名全職開發人員專門貢獻給SharePoint。不是開發者的1/2或1/3。您需要承諾並專注於正確開展SharePoint開發。你必須喝Kool-Aid。如果你不願意專注於SharePoint，但只願意涉足，那麼最終的解決方案是可怕的（恕我直言）。如果您可以奉獻兩名開發人員或一個團隊（想想可支持性/維護/專業知識/專業化），那更好。

那麼你怎麼看？

說明：我認爲，如果微軟的商店選擇將其與Exchange配對作爲其協作架構的一部分，那麼所有的微軟商店都應該使用SharePoint的開箱即用功能。我不是反SharePoint。

UPDATE
坐在SP車間後，我已經瞭解到，SharePoint工作流只適用每個SharePoint列表項目的基礎上。因此，如果您的工作流程不使用SharePoint列表項目，那麼您應該查看.NET Workflow基礎或某種自定義項目。考慮這個替代我的＃2項目。

Answer 1

我同意。 Sharepoint目前（moss 2007/wss 3.0）使定製開發過程非常痛苦和緩慢。我不同意的唯一觀點是工作流程部分。在我看來，SharePoint中的工作流幾乎不可用，應該避免。如果您要執行工作流程，請使用k2：blackpearl或MassTransit作爲開源免費選項。

Answer 2

比方說，您有一個數據倉庫可以從公司的多個點收集數據。希望你有幾個維度可以讓商界人士指定爲「維度所有者」。這些是維度中組織數據的人。他們負責保留層次結構和列表等最新信息，但這些集合中不包含來自事務性系統的操作數據，它們是業務術語，組和業務說明的描述。這是他們自然的商業語言。東部銷售團隊，小型企業，高風險，平面廣告促銷25等等。關鍵是您的數據倉庫是由99％的運營/交易內容構建而成的，但是它的業務安排使其對您的用戶來說都是明智的，您需要捕捉它的地方。

你當然可以做一個網絡應用程序。您可以使用Excel文件。隨你。但是你也可以使用SharePoint列表。如果SharePoint對此有吸引力，那麼當環境已經存在（並因此得到支持）時，當您的需求不是很廣泛時，即不需要參照完整性時，您就沒有資源來創建新的Web應用程序，那麼業務用戶已經熟悉和舒適的SharePoint，你需要它昨天等

所以我不是在這裏談論編寫代碼和編譯庫安裝在SharePoint上。我只是想提出一個合理的「合適的時間和地點」來使用它。

順便說一句 - 這是一個非常方便how-to on pushing and pulling data between SharePoint lists and SSIS。

Answer 3

SharePoint應該用作商業用戶協作（即存儲，查找和編輯每個其他文檔）的基礎。僅僅將SharePoint用於應用程序開發會很痛苦，並且需要在問題中提出第3點。

對於應用程序開發，我更喜歡使用SharePoint作爲Web門戶，將用戶指向應用程序或託管其Web界面（通過用戶控件，Web部件等）（哦，等等，我都準備好說SharePoint是一個Web門戶）。

Answer 4

即使沒有文檔，仍然可以使用Sharepoint作爲帶有自定義Web部件（可能其中一些基於站點文檔庫）的門戶平臺。這是一個很好的門戶平臺，我的公司研究門戶是基於sharepoint的，它工作得很好。好處是，通過這些基於webparts的Sharepoint門戶，您仍然可以相對輕鬆地處理權限問題和演示文稿定製問題（將webpart拖到特定區域等，用戶做了很多事情）。此外，WSRP類型的webparts與Sharepoint的工作相當不錯。

如果你有好的Sharepoint開發者，那麼你是對的，那麼它確實讓你變得容易，是一個體面的平臺，文檔或沒有文檔。