我们的组织大约在两年前开始走上 SharePoint 之路。在此之前，我们（开发人员）主要为 SQL 后端编写 asp.net 前端。现在似乎每次出现新项目时，我们都被要求“使其”适合 SharePoint；由于复杂性和与其他技术的交互，我们在 SharePoint 中塞入了一些本来应该是独立应用程序或 Web 应用程序的东西。
我的问题是：对于在 SharePoint 和 Web/Winform 应用程序中开发项目，您在哪里划定界限，您如何让您的经理相信 SharePoint 可能不是特定项目的最佳解决方案？
【问题讨论】：
标签： sharepoint moss wss
我有点同意你的看法，这有时是一个棘手的问题。不过，总的来说，我同意陈词滥调，即您只需要稍微不同地考虑共享点应用程序即可。如果您的数据可以被认为是基于列表的，那么 SharePoint 可能不一定是一个糟糕的开发框架。表面上看起来似乎需要做更多的工作，但 IMO 的挑战只是从一个地方转移到另一个地方。如果您使用自定义字段模板和 Web 部件之类的东西，您可以相对自然地处理各种数据。您还可以免费获得 SharePoint 的积极方面（已经成熟的安全框架、内置搜索、网站和列表模板/定义、个性化页面自定义、yada、yada）。
我也不知道您在这里所说的“复杂性和与其他技术的交互”是什么意思，因此很难想象将 SharePoint 添加到组合中时可能会引入哪些具体问题。
如果您的开发团队在 SharePoint 方面相对缺乏经验，并且您关心质量和截止日期，那么我绝对可以理解您的观点。这不是一个简单的学习曲线，但我认为 SharePoint 产品比许多人认为的更自然地可扩展。
【讨论】：
在某些情况下，SharePoint 应用程序和 ASP.NET 应用程序之间存在第三种选择。您可以构建自定义网站和应用程序页面并将它们部署到 SharePoint 网站。 （Inside Windows SharePoint Services 3.0 一书很好地概述了如何执行此操作。）这将允许您在 SharePoint 环境中使用 ASP.Net 和 SQL Server（这意味着您还可以利用 SharePoint 安全性等功能）。它不像开发一个普通的 ASP.Net 应用程序那么容易，但它是一种折衷方案。
当然，如果他们希望这些新应用程序建立在 SharePoint 技术（列表、库、工作流等）之上，而不仅仅是“在”SharePoint 内部，这在某种程度上是一种技术性问题。
【讨论】：
您可能会在 SP 中放置应用程序的主要原因之一是您想利用 SP 为您提供的构建块：
【讨论】：
在尝试将新应用“集成”到现有池中时要考虑的一件事是，数据（客户、库存等）是否存在任何重叠，可以从合并中受益。
还有一个好处是能够在一个地方备份多个应用程序及其各自的所有数据。
【讨论】：
他们为什么要求将所有内容都放到 SharePoint 中？
根据我的经验，这是因为 'ole SharePoint Intranet 作为一个门户非常棒，可以将所有内容放在一起并在一个信息架构下查找。
从对组织中应用程序空间的使用感知来解决问题。
只要应用程序的外观和感觉就像 Intranet 站点的一部分，并且用户不必考虑如何访问它（以及如何退出），您几乎可以做出任何必要的架构决策在实施和维护方面为组织争取最大收益。
当我们开始考虑较少从 SharePoint 与其他东西到信息架构、可查找性和可用性等漂亮的毛茸茸概念的网站时，我们决定不将其实际放在 SharePoint 中，但仍然像 Intranet 一样对其进行皮肤变得更容易销售.
【讨论】：