我目前正在研究开发应用程序，并可以选择执行标准ASP.NET Web应用程序或将其集成到SharePoint中 . 如果可能的话，我们的客户希望它是SharePoint，因为他们面临着将所有新开发纳入其中的压力，但标准ASP.NET仍然是一种选择 .
它是一个应用程序，用于管理和查看包含大约10个表的数据库中的数据，包括添加某些新项目时的批准工作流程 . 数据的参照完整性很重要 .
我有开发ASP.NET应用程序的经验，但对SharePoint很少 . 有没有人有任何标准适用于两者之间的决定？
到目前为止，我正在思考：
-
数据的参照完整性非常重要，如果不编写大量自定义代码，SP似乎无法很好地处理这些问题
-
SharePoint在列表中建议的2000项限制似乎不可扩展
-
该应用程序具有批准工作流程，这似乎是SP做得很好的事情
总的来说，似乎我们最终会编写大量自定义代码而不是真正使用任何开箱即用的SP功能 . 所以我的想法是为什么不只是编写一个标准的ASP.NET应用程序 .
我们还应该考虑其他关键事项吗？
3 回答
到目前为止，您可能已经找到了这个链接：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框架提供了有 Value 的基于Web的服务，因此SharePoint在ASP.NET之上提供了其他服务和功能 . 该平台无需编写通用代码片段，这些代码片段是许多ASP.NET应用程序的一部分：安全代码，用户配置文件管理，个性化，UI / UX基线等 . 当您进入管道时，您将获得更多：丰富的缓存支持，需要最少的配置，通过功能定制模块化等等 .
是应该在SharePoint中构建每个应用程序？我永远不会那样做 . 使用我当前的客户端，我们使用基于SharePoint和自定义ASP.NET应用程序的混合 . 应用程序是在SharePoint中构建还是在ASP.NET中从头开始编写，这是我们正在做的事情的一个功能 . 我们进行同样的运动 . 如果可以使用SharePoint的特性和功能来缩短开发时间，则可以使用SharePoint . 如果需求过于具体或者我们认为我们正在使用SharePoint，我们会使用自定义应用程序路径 .
你对你的应用程序有一些非常具体的顾虑，所以让我用他对你的要求了解的一点点来解决它们：
REFERENTIAL INTEGRITY：根据您所说的，听起来您的数据模型非常具体 . 然而，构建您的信息体系结构以本地利用站点列，内容类型和列表可能并不会使SharePoint退出 . 有's absolutely no reason why you couldn' t构建您想要的数据模型（可能在SQL Server中），然后使用驻留在SharePoint中的组件来使用它 . 如果您仍然在编写控件和/或页面来处理数据，那么正确吗？使用SharePoint作为直接访问SQL的表示层或（以更可扩展的n层方式）与其他地方的业务服务相比，没有任何问题 .
2000项目限制：这是一个共同关注的问题，也是一个被误解的问题 . 没有2000列表项限制;实际测量是每个视图2000个项目（并且's with out of the box views, by the way) or 1107843 (such as a folder). You can store many more times that (millions, if you like) in a list if you partition with folders, build your own view to page, etc. Again, given your data structure and the likely need you have to dodge SharePoint' s列表，如果您只是从SQL Server中消耗数据，这将不是问题 .
工作流程：SharePoint作为工作流主机很好用，OOTB工作流程很方便 . 我假设您正在关注MOSS（与直接WSS相比），但以防万一：审批工作流程附带MOSS . 如果您受限于WSS，则只有一个工作流可供您使用：三态工作流 .
在一天结束时，SharePoint是.NET并且构建在ASP.NET之上 . 无论如何，你需要在自定义.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应用程序，智能客户端，命令行应用程序，以及更多 . 它只是归结为“我得到的”为“我所花的”（在时间和金钱上） .
我希望这有帮助！
您的评估非常准确 . （这将有助于获得有关您的应用程序所需的每个功能的更多细节，但这对于此介质并不实用 . ）
您提到的问题已基本解决，但您需要了解并实施解决方案 . 例如，有一个CodePlex项目可以帮助引用完整性，并且有关于如何管理列表中项目数的建议 . 但是使用SharePoint永远不会让您自由地从头开始编写ASP.NET应用程序 .
另一件需要考虑的事情是您和/或客户期望应用程序将来如何发展 . 如果需要更多协作式功能或功能（如列表项的版本历史记录以及与Office客户端集成），则SharePoint可能是更好的选择 .
您还应该考虑在SharePoint上部署和更新应用程序的复杂性 .