我目前正在开发一个应用程序，可以选择制作标准的ASP.NET Web应用程序或将其集成到SharePoint中。我们的客户希望尽可能使用SharePoint，因为他们面临将所有新开发放入其中的压力，但标准的ASP.NET仍然是一个选项。
这是一个管理和查看数据库中大约有10个表的数据的应用程序，包括在添加某些新项目时进行批准工作流程。数据的引用完整性很重要。
我有开发ASP.NET应用程序的经验，但对SharePoint的了解非常少。有没有人有任何标准来决定两者之间的区别？
到目前为止，我的想法是：
总体上，似乎我们最终会编写大量自定义代码，并且不会真正使用任何现成的SP功能。因此，我的想法是为什么不只编写标准的ASP.NET应用程序。
还有其他关键因素需要考虑吗？
引用完整性: 根据你所说的，你的数据模型非常特定。本地利用站点列、内容类型和列表建立信息架构可能没有意义。但这并不排除使用SharePoint的可能性。你完全可以构建你想要的数据模型（很可能在SQL Server中），然后使用驻留在SharePoint中的组件消耗它。如果你使用MOSS，则一些BDC WebParts可能适合你。如果不是，你仍然需要编写控件和/或页面来处理数据，对吧？使用SharePoint作为访问SQL直接或（以更可扩展的n层方式）针对其他业务服务的呈现层也没问题。
2000项限制: 这是一个常见的问题，也是一个被误解的问题。不存在2000个列表项的限制；实际的测量标准是每个视图（通过"out of the box views"）或容器（例如文件夹）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可能会在以后得到回报。你的评估非常准确。（虽然在这个媒介上详细了解应用程序所需的每个功能会更有帮助，但这并不实际。）
你提到的问题已经基本得到解决，但你需要理解并实施解决方案。例如，有一个CodePlex项目可以帮助处理参照完整性，并有关于如何管理列表中的项目数量的建议。但使用SharePoint永远无法给你像从头开始编写ASP.NET应用程序那样的自由。
另一件需要考虑的事情是你和/或客户期望应用程序将来如何发展。如果需要更多协作式功能或诸如列表项版本历史记录和与Office客户端集成等功能，则SharePoint可能是更好的选择。
您还应考虑在SharePoint上部署和更新应用程序的复杂性。
