sharepoint - 如何确定应用程序是否适合SharePoint？

Question

我目前正在开发应用程序，可以选择执行标准ASP.NET Web应用程序还是将其集成到SharePoint中。我们的客户希望在可能的情况下成为SharePoint，因为他们面临将所有新开发纳入其中的压力，但是标准ASP.NET仍然是一个选择。

它是一个用于管理和查看大约10个表的数据库中数据的应用程序，包括添加某些新项目时的批准工作流。数据的参照完整性很重要。

我有开发ASP.NET应用程序的经验，但对SharePoint却很少。有人在决定两者之间适用时有任何标准吗？

到目前为止，我正在考虑以下方面:

数据的引用完整性很重要，如果不编写大量自定义代码

，SP似乎无法很好地处理此问题。

SharePoint似乎不太可扩展，列表

列表中建议的限制为2000个项目

该应用程序具有批准工作流，这似乎是SP表现出色的事情

从总体上看，我们似乎最终会写很多自定义代码，而实际上并没有真正使用任何现成的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工作，则可以使用自定义应用程序路线。

您对您的应用程序有一些非常具体的关注，所以让我以对您的要求了解得很少的一点来解决它们:

参考完整性:根据您的意思，听起来您的数据模型非常具体。构建信息架构以本地利用网站列，内容类型和列表可能没有意义。但是，这并不会排除SharePoint。绝对没有理由不能构建所需的数据模型(大概在SQL Server中)，然后再将其与SharePoint中的组件一起使用。如果您使用的是MOSS，则某些BDC WebPart可能会立即为您工作。如果没有，您仍然会编写控件和/或页面来处理数据，对吗？将SharePoint用作直接访问SQL的表示层或(以更具可伸缩性的n层方式)与其他地方的业务服务相抵触没有错。

2000项目限制:这是一个普遍关注的问题，并且被误解了。没有2000个列表项限制；实际的度量是每个视图2000个项目(顺便说一下，这是开箱即用的视图)或“容器”(例如文件夹)。如果使用文件夹进行分区，在页面上建立自己的视图等，则可以在列表中存储更多(如果需要，可以存储几百万次)。同样，鉴于您的数据结构和可能需要避开SharePoint列表的情况，如果仅使用SQL Server中的数据就不会有问题。

的工作流程:SharePoint作为工作流的宿主很好，并且OOTB工作流非常方便。我假设您正在查看MOSS(相对于直接WSS)，但以防万一:MOSS附带了审批工作流。如果您受限于WSS，则只有一个工作流程可供使用:三态工作流程。

归根结底，SharePoint是.NET，并且建立在ASP.NET之上。无论如何，您必须在SharePoint应用程序中编写的许多代码都需要在自定义.NET中编写。我将从理解SharePoint是否为您(作为开发人员)提供的体验和功能可以帮助您加快开发周期和/或改善用户体验(作为开发人员，我们有时忘记了这一点)的角度来看待事情。

但是，Dakota中的David确实有一个很好的观点，因为SharePoint的开发经验不同于直接的ASP.NET。需要通过功能进行部署(或更确切地说是最佳实践)，了解特定的SharePoint问题(例如，SharePoint对象的寿命和处置)等，这意味着如果您确实在SharePoint中进行构建，则将需要大量时间。有很多不错的资源(包括StackOverflow上的人员)可以提供帮助，但是您需要将一些学习因素纳入SharePoint是否有意义的等式中。

还有一个分开的想法:微软正在慢慢地改变自己的许多产品和平台，以利用SharePoint作为其UI / UX层，并且趋势正在加速发展。 PerformancePoint，Project Server，Team Foundation Server和Commerce Server都使用SharePoint作为其表示层。这种趋势可能会继续，尽管我不知道要走多远。如果您使用其中任何一种产品(或技术路线图上的产品)，则SharePoint投资现在可能会在以后获得回报。

尽管我写过很多关于SharePoint的文章，但我并不认为它在每种情况下都是正确的工具。我仍在构建WinForms应用程序，智能客户端，命令行应用程序等等。只是权衡“我所得到的”与“我所花费的”(在时间和金钱上)。

我希望这有帮助!