我正在评估Sharepoint（不是MOSS）与ASP.NET作为我们团队即将推出的解决方案的开发平台。我们将为各种环境中的广泛（我们希望）部署开发解决方案。我正在确定用于评估每个平台选择的优缺点的类别。我选择了适用于我们的解决方案要求的类别，这将影响开发人员/测试人员的工作效率。任何人都可以想到适合比较的任何其他类别吗？任何人都可以提供有关这两个平台在任何类别方面的经验的任何细节吗？
其他一些信息，我们有两个短的时间来发布内容，所以我们在说话时优先考虑功能。我们将Sharepoint视为一种快速解决问题的方法，同时利用UI框架为基本UI，安全性以及列表和文档库进行存储。
冗余/复制/备份/恢复支持
答案 0 :(得分：5)
我没有看到成本。
答案 1 :(得分：3)
您的解决方案是否与协作或Web内容管理有关？如果没有，将SharePoint添加到组合中并不是一个好主意。
使用WSS 3.0作为开发平台而不是ASP.NET需要一些严肃的理由，并且无法从您对解决方案的有限描述中说出为什么您会考虑这一点。
在所有测量方面，在SharePoint平台上创建开发会增加复杂性，从而降低开发成本。
<强>更新
我看到了Sharepoint安全性，文档库，UI框架和 缺乏必须建设和 测试数据库是一个很好的生产力 增强剂。那些是Sharepoint 我们可以大大受益的功能 从
SharePoint对这些项目的好处远远超过学习，编码和支持SharePoint的成本方面。 ASP.NET为这些项目提供了简单的解决方案，并且更易于管理。使用过这两种产品后，您将希望继续使用ASP.Net
请记住，SharePoint列表没有任何关系完整性，因此创建除了SharePoint中列表之间的微不足道的关系之外，最终大量比创建连接语句和一些存储过程更加昂贵
在不了解项目的更多细节的情况下，我不能完全排除SharePoint作为解决方案。
虽然可以将SharePoint用作开发平台，但如果您没有与您合作的SharePoint专家可以回答您的问题，那么您的项目将无法获得足够的SharePoint技能以使其成功。
答案 2 :(得分：1)
可伸缩性
许可限制
扩展
复杂
概念完整性（域边界）
供应商锁定/开放系统支持
冗余/复制/备份/恢复支持
答案 3 :(得分：1)
正式地说，为了开发WSS解决方案，所有开发人员都需要让他们的开发环境在 WSS服务器上运行。我认为这是消极的。
请参阅Somasegar的Sharepoint tools support in Visual Studio下的许多评论。
我要说的是，由于您的截止日期很短，您还要考虑到SharePoint社区存在的SharePoint开发人员社区要小得多。将标记为“ASP.NET”的SO上的文章数量与标记为“SharePoint”的文章进行比较。
我会在短期内使用ASP.NET，了解您可能能够重构您的应用程序以便在较长时间内使用SharePoint。使用类似于列表的数据库结构或您在SharePoint中创建的其他内容类型。保持类似的部署模型。您可以随意使用工作流，但它应该与SharePoint的工作流功能并行。您甚至可以以类似的方式布置页面。这样，当您有更多时间时，可以更轻松地迁移到SharePoint。
答案 4 :(得分：0)
我们使用SharePoint作为我们构建的大多数应用程序的组件，因为它能够创建和管理列表和内容类型（以及自动CRUD），版本控制，权限模型和工作流工具。
我们开发了SLAM，SharePoint列表关联管理器，以克服SharePoint数据不是关系的明显限制。因为它将SharePoint数据推送到SQL Server，所以它允许我们仅在前端只使用ASP.NET的“后端”上使用SharePoint，这是我们经常使用的配置。
我们已将SLAM作为开源项目发布，因此开发社区的其他成员可以利用这种方法并帮助我们扩展它。
快乐砰的一声！
阿伦