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

Question

我目前正在研究开发应用程序,并可以选择执行标准ASP.NET Web应用程序或将其集成到SharePoint中.如果可能的话,我们的客户希望它是SharePoint,因为他们面临着将所有新开发纳入其中的压力,但标准ASP.NET仍然是一种选择.

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

我有开发ASP.NET应用程序的经验,但对SharePoint很少.有没有人有任何标准适用于两者之间的决定？

到目前为止,我正在思考:

• 数据的参照完整性非常重要,如果不编写大量自定义代码,SP似乎无法很好地处理这些问题
• 对于列表中的2000个项目的建议限制,SharePoint似乎不具有可扩展性
• 该应用程序具有批准工作流程,这似乎是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,我们会使用自定义应用程序路径.

你对你的应用程序有一些非常具体的顾虑,所以让我用他对你的要求了解的一点点来解决它们:

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提供的经验和功能(作为开发人员)是否有助于加快开发周期和/或改善用户体验(我们作为开发人员,有时会忘记)的角度来看待事物.

但是,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应用程序,智能客户端,命令行应用程序,以及更多.它只是归结为"我得到的"为"我所花的"(在时间和金钱上).

我希望这有帮助!