如何決定應用程序是否適合SharePoint？

Question

我目前正在開發一個應用程序，並在做一個標準的ASP.NET Web應用程序或將它集成到SharePoint之間進行選擇。如果可能，我們的客戶希望它是SharePoint，因爲他們承受着將所有新開發放入其中的壓力，但標準ASP.NET仍然是一種選擇。

它是一個應用程序，用於管理和查看數據庫中的數據，包含約10個表格，其中包括添加某些新項目時的審批工作流程。數據的參照完整性很重要。

我有開發ASP.NET應用程序的經驗，但對SharePoint很少。有沒有人有適用於決定兩者之間的標準？

到目前爲止，我的線沿線的思考：

• 數據的引用完整性很重要，SP似乎並沒有處理這個非常好，而無需編寫大量的自定義代碼
• 的SharePoint沒有按」噸名單似乎非常具有可擴展的2000項建議的限制
• 的應用已審批工作流程，這似乎是一些SP做的好

在th整體而言，我們似乎最終會寫很多自定義代碼，而不是真正使用任何開箱即用的SP功能。所以我的想法是，爲什麼不寫一個標準的ASP.NET應用程序。

我們應該考慮其他關鍵的事情嗎？

Answer 1

現在，您可能已經找到此鏈接：http://blogs.msdn.com/sanjaynarang/archive/2009/06/19/should-i-build-my-application-in-sharepoint-vs-asp-net.aspx。如果沒有，這是一個體面的起點，有一些很好的問題要問。

下面是我採取的是一個長期的.NET開發人員（只要該平臺已經出現）和一個SharePoint建築師（2003年起）。這基本上是我的方式，說我一直在圍欄的兩邊。

在我看來，SharePoint是一個平臺，而不是產品。由於ASP.NET爲核心.NET框架提供了有價值的基於Web的服務，SharePoint在ASP.NET之上提供了額外的服務和功能。該平臺消除了編寫如此多ASP的一部分的通用代碼段的需求。NET應用程序：安全代碼，用戶配置文件管理，個性化，UI/UX基線等等。進入管道時，您將獲得更多：豐富的緩存支持，需要最少的配置，通過功能定製模塊化等等。

是否應該在SharePoint中構建每個應用程序？我永遠不會爲此而努力。使用我目前的客戶端，我們使用了基於SharePoint和自定義ASP.NET應用程序的組合。一個應用程序是否構建在SharePoint中與從頭開始編寫ASP.NET是我們正在做的功能。我們進行同樣的練習。如果可以利用SharePoint的功能和功能來縮短開發時間，它就會在SharePoint中使用。如果需求太具體，或者我們覺得我們會在SharePoint上工作，那麼我們就會使用自定義應用程序路線。

你必須爲你的應用一些非常具體的關注，所以讓我來破解他們與小我瞭解你的需求：

1. 引用完整性：根據你說的話，它聽起來像你的數據模型是非常具體的。構建您的信息架構以本地利用網站欄，內容類型和列表可能沒有意義。儘管如此，這並不會讓SharePoint崩潰。絕對沒有理由不能建立你想要的數據模型（大概是在SQL Server中），然後將它用於駐留在SharePoint中的組件。如果您使用MOSS，則一些BDC WebParts可能會爲您直接工作。如果不是，你仍然在編寫控件和/或頁面來處理數據，對嗎？將SharePoint用作直接訪問SQL的表示層或（以更具伸縮性的n層方式）對其他地方的業務服務進行逆向處理沒有任何問題。

2. 2000項目限制：這是一個常見問題，也是一個被誤解的問題。沒有2000個列表項限制;實際測量值爲2000個項目每個視圖（順便說一句，這是開箱即用的視圖）或「容器」（如文件夾）。如果您使用文件夾進行分區，建立自己的頁面視圖等，您可以將更多次（百萬，如果您喜歡）存儲在列表中。同樣，考慮到您的數據結構和可能需要避開SharePoint列表，如果你只是簡單地使用SQL Server的數據就不會成爲問題。

3. 工作流：作爲工作流主機，SharePoint非常好，而OOTB工作流非常方便。我假設你正在看MOSS（而不是直WSS），但以防萬一：審批工作流程隨MOSS一起提供。如果您受限於WSS，則只能爲您提供一個工作流程：三態工作流程。

在這一天結束時，SharePoint 是 .NET和建立在ASP.NET之上。無論如何，您必須在SharePoint應用程序中編寫大部分代碼才能在自定義.NET中編寫代碼。從理解SharePoint向您（作爲開發人員）提供的體驗和功能是否可以幫助您加速開發週期和/或改善用戶體驗（我們作爲開發人員有時會忘記的內容）的角度來看，我會研究一些事情。

David在達科他州的確有很好的一點，因爲SharePoint的開發經驗與直接的ASP.NET不同。通過功能進行部署的需求（或更確切地說，最佳實踐），瞭解特定的SharePoint關注點（例如，SharePoint對象的生存期和處置）等等，這意味着如果您在SharePoint中構建，則需要增加時間。這裏有相當多的優秀資源（包括StackOverflow中的人員）可以提供幫助，但是您需要將一些學習納入SharePoint是否合理的等式中。

還有一個臨別認爲：微軟正在緩慢地改變着許多自己的產品和平臺，以充分利用的SharePoint作爲他們的UI/UX層，而且這種趨勢正在加速一些蒸汽。 PerformancePoint，Project Server，Team Foundation Server和Commerce Server都將SharePoint用作其表示層。這種趨勢可能會持續下去，但我不知道有多遠。如果您使用這些產品中的任何一種（或者在您的技術路線圖上使用這些產品），現在SharePoint投資可能會在以後得到回報。

儘管所有我對寫作和倡導的SharePoint，我不認爲這是在每一個場景的工具。我仍然構建WinForms應用程序，智能客戶端，命令行應用程序，以及更多。它只是歸結爲「我得到的」「我花了什麼」（無論是時間還是金錢）。

我希望這有助於！

Answer 2

您還應該考慮在SharePoint上部署和更新應用程序的複雜性。

Answer 3

您的評價相當精確。 （這將有助於有更詳細的瞭解每一個功能，您的應用需求，但是這不是真正實用這個媒介。）

你提到已經在很大程度上解決的問題，但你需要理解和執行該方案。例如，有一個CodePlex項目可以幫助參照完整性，並提供有關如何管理列表中項目數量的建議。但是使用SharePoint永遠不會給您從頭開始編寫ASP.NET應用程序的自由。

另一個要考慮的是你和/或客戶端如何期望應用程序將在未來的演變。如果它需要更多協作樣式的功能或功能，例如列表項上的版本歷史記錄以及與Office客戶端的集成，那麼SharePoint可能是更好的選擇。