将 Sharepoint 与 ASP.NET 作为开发平台进行评估

Posted 2023-03-08

【中文标题】将 Sharepoint 与 ASP.NET 作为开发平台进行评估

【英文标题】：Evaluating Sharepoint vs ASP.NET as a development platform

【发布时间】：2010-10-19 12:20:26

【问题描述】：

我正在评估 Sharepoint（不是 MOSS）与 ASP.NET 作为我们团队即将推出的解决方案的开发平台。我们将为跨各种环境的广泛（我们希望）部署开发解决方案。我正在确定类别以评估每个平台选择的优缺点。我选择了适用于我们的解决方案要求并且会影响开发人员/测试人员生产力的类别。谁能想到任何其他适合进行比较的类别？任何人都可以提供任何关于您在这两个平台上的任何类别的体验的详细信息吗？

其他一些信息，我们有短短两个月的时间来发布某些内容，因此我们正在优先考虑功能。我们将 Sharepoint 视为一种快速推出产品的方式，同时将 UI 框架用于基本 UI、安全性以及用于存储的列表和文档库。

开发环境 开发者生产力 功能可测试性 开发人员可测试性（单元测试） 基于角色的安全性 基于视图的安全性 用户体验 数据库 - 基于使用列表的 Sharepoint 易于开发。但是，将报告添加为要求会使使用列表成为障碍。 报告 - Sharepoint 让这变得困难 文档存储库 - 我们的解决方案将需要多个文档库将工件附加到解决方案元素 包装 安装 - Sharepoint 通过 WSP 为我们提供了简单的 famr 安装。 可扩展性 可扩展性 复杂性 概念完整性（域边界）

冗余/复制/备份/恢复支持

【参考方案1】：

我们使用 SharePoint 作为我们构建的大多数应用程序的组件，因为它能够创建和管理列表和内容类型（以及自动 CRUD）、版本控制、权限模型和工作流工具。

我们开发了 SLAM，即 SharePoint 列表关联管理器，以克服 SharePoint 数据不是关系方面的明显限制。因为它将 SharePoint 数据推送到 SQL Server，它允许我们仅在“后端”使用 SharePoint，而前端仅使用 ASP.NET，这是我们经常使用的配置。

我们已将 SLAM 作为开源项目发布，因此开发社区的其他成员可以利用这种方法并帮助我们扩展它。

http://slam.codeplex.com

祝你快乐！

艾伦

【参考方案2】：

您的解决方案是否与协作或网络内容管理有关？如果没有，将 SharePoint 添加到组合中并不是一个好主意。

使用 WSS 3.0 作为开发平台而不是 ASP.NET 需要一些严肃的理由，而且从您对解决方案的有限描述中无法判断您为什么会考虑这样做。

在所有衡量方面，在 SharePoint 平台上创建开发会增加复杂性，因此会增加任何开发工作的成本。

更新

我看到了 Sharepoint 安全性、文档库、UI 框架和 无需建造和 测试数据库作为伟大的生产力 增强剂。这些是Sharepoint 我们可以从中受益的功能 来自

SharePoint 对这些项目的好处远远超过了学习、编码和支持 SharePoint 的成本方面。 ASP.NET 以更易于管理的方式为这些项目提供了简单的解决方案。使用过这两种产品后，您会希望继续使用 ASP.Net

请记住，SharePoint 列表不具有任何类型的关系完整性，因此在 SharePoint 中创建任何列表之间的无关紧要的关系最终会大量比创建连接语句和一些存储过程更昂贵.

在不了解项目的更多细节的情况下，我不能完全排除 SharePoint 是一种解决方案。

虽然可以将 SharePoint 用作开发平台，但如果您没有 SharePoint 专家与您合作来回答您的问题，那么您的项目将没有足够的 SharePoint 技能来使其成功。

【讨论】：

我们没有使用 Web 内容管理（MOSS 没有被评估），除了拥有文档库之外，协作不是必需的。

我看到了 Sharepoint 安全性、文档库、UI 框架以及无需构建和测试数据库作为伟大的生产力增强器。这些是我们可以从中受益匪浅的 Sharepoint 功能。

【参考方案3】：

正式地，为了开发 WSS 解决方案，您的所有开发人员都需要让他们的开发环境在 WSS 服务器上运行。我认为这是负面的。

查看Sharepoint tools support in Visual Studio 下的许多 cmets by Somasegar。

我想说，由于您的截止日期很短，您还考虑了一个事实，即 SharePoint 开发人员社区比 ASP.NET 社区小得多。比较 SO 上标记为“ASP.NET”的文章数量与标记为“SharePoint”的文章数量。

我会在短期内使用 ASP.NET，了解您可以重构您的应用程序以在长期内使用 SharePoint。使用类似于您在 SharePoint 中创建的列表或其他内容类型的数据库结构。保持类似的部署模型。随意使用工作流，但它应该可能与 SharePoint 的工作流功能平行。您甚至可以以类似的方式布置您的页面。这将使您在有更多时间时更容易迁移到 SharePoint。

【讨论】：

谢谢约翰。我将更新工具类别以反映开发环境。我们已经提供了我们的开发环境（Win2k8 在 HyperV 中使用 Sharepoint / VS.NET 和 TFS 访问）。

我真的不能同意这一点。如果您没有积极地针对 SharePoint 进行开发，并且希望能够以无缝方式迁移 asp.net 工件/代码；你会很失望的。

@Jason：请再次阅读我的回复。我告诉他使用 ASP.NET 而不是 SharePoint。

【参考方案4】：

可扩展性 许可限制 可扩展性 复杂性 概念完整性（域边界） 供应商锁定/开放系统支持 冗余/复制/备份/恢复支持

【讨论】：

我认为您应该详细说明这些参数，或者至少为每个选项提供相关指标。

我想，但问题中没有足够的上下文来确定它们的相对重要性。我认为让这个评估有意义是一个挑战（尽管我可以帮助填写清单。）

首先应该将其评估为交付平台，而不是开发平台。甚至不清楚它们是否旨在成为同一事物，尽管我认为这很可能。

【参考方案5】：

我没有看到成本。

【讨论】：

成本将是上述许多评估的结果。