是否使用 SharePoint（作为应用程序开发的基础）（与 ASP.NET 相比）答案

【问题标题】：To SharePoint Or Not (as a foundation for application development)(vs ASP.NET)是否使用 SharePoint（作为应用程序开发的基础）（与 ASP.NET 相比）
【发布时间】：2010-11-13 18:15:31
【问题描述】：

我有一个 POV，您应该只在这些条件下使用 SharePoint 进行应用程序开发。

1) 应用程序使用文档，并且这些文档需要 SharePoint 非常擅长的某种功能（搜索/索引、与 Outlook 同步等...）如果您想要的只是一个文档桶和一个列表，那么 ASP。 NET 或 ASP.NET MVC。

2) 应用程序必须使用工作流或自定义工作流。没有工作流，我会再看 ASP.NET 或 ASP.NET MVC。

3) 公司必须愿意为 SharePoint 提供至少 1 名全职开发人员。不是开发人员的 1/2 或 1/3。您需要投入和专注才能正确进行 SharePoint 开发。你必须喝Kool-Aid。如果您不愿意专门研究 SharePoint，而只愿意涉足，那么最终的解决方案将是糟糕的（恕我直言）。如果您可以让两个开发人员或一个团队投入使用（考虑可支持性/维护/专业知识/专业化），那就更好了。

那你怎么看？

注意：我认为所有 Microsoft 商店都应该使用 SharePoint 的开箱即用功能，如果他们的公司选择将其与 Exchange 配对作为其协作架构的一部分。我不反对 SharePoint。

更新
在参加 SP 研讨会后，我了解到 SharePoint 工作流仅适用于每个 SharePoint 列表项。因此，如果您的工作流不使用 SharePoint 列表项，那么您可能应该查看 .NET Workflow 基础或自定义的东西。考虑将其替换为我的 #2 项目。

【问题讨论】：

我认为项目需要适合 SharePoint 的部分原因是开发模型。比如部署代码到GAC，重启应用池。大型企业 SharePoint Intranet 服务器的颈部疼痛。

标签： .net asp.net sharepoint collaboration

【解决方案1】：

我同意。 Sharepoint 当前（moss 2007/wss 3.0）使自定义开发成为一个非常痛苦和缓慢的过程。我唯一不同意的一点是工作流程部分。在我看来，SharePoint 中的工作流几乎无法使用，应该避免使用。如果您要进行工作流程，请选择 k2:blackpearl 或 MassTransit 以获取开源免费选项。

【讨论】：

让我澄清一下。我没有说 SP 工作流程很棒。我的意思是，如果您的应用程序没有工作流，为什么不使用 ASP.NET？顺便说一句，大众运输发生了什么。这个项目还很活跃吗？ +1 缓慢而痛苦。
是的，MassTransit 仍然有效。 Chris Patterson 的主要开发人员之一在塔尔萨，他所在的公司在其内部生产系统中使用，所以即使它还没有达到 v1.0，我认为它相当稳定......
现在希望 MSFT 能够在 2010 年解决很多开发痛点。我有一点希望，在 2010 年进行定制开发会是一个更好的价值主张。

【解决方案2】：

假设您有一个数据仓库，可以从公司的多个点收集数据。希望您有一些维度将业务人员指定为“维度所有者”。这些人与维度中的数据组织息息相关。他们负责使层次结构和列表等内容保持最新，但这些集合没有填充来自事务系统的操作数据，它们是业务术语和组以及业务所说的描述。这是他们天生的商业语言。 East Sales Team、Small Business、High Risk、Print-Ad Promotion 25 等。关键是您的数据仓库是由 99% 的运营/事务性材料构建的，但正是业务安排让您的用户觉得一切都合理，您需要一个捕捉它的地方。

您当然可以制作一个网络应用程序。您可以使用 Excel 文件。任何。但您也可以使用 SharePoint 列表。 SharePoint 对此有吸引力的地方是环境已经存在（因此受到支持），当您的要求不广泛时，即不需要参照完整性，您没有资源来创建新的 Web 应用程序，业务用户已经熟悉并熟悉 SharePoint，您昨天需要它，等等。

所以我在这里不是在谈论编写代码和编译要安装在 SharePoint 上的库。我只是想提出一个合理的“正确的时间和地点”供它使用。

顺便说一句 - 这是一个非常方便的how-to on pushing and pulling data between SharePoint lists and SSIS。

【讨论】：

我可以看到你来自哪里。但是在 4 周内，您可以非常接近地复制 SharePoint 中的基本列表功能。然后您可以完全控制该应用程序。您不必通过您无法控制的抽象来工作。我希望 MS 做一些事情来使从 SP 列表中获取数据更容易。如果这是微软战略的核心部分，那么获取数据应该像 ODBC 一样简单。 +1 好争论和链接
如果您使用像 MetaMan 这样的自定义工具，那么使用 SP 作为企业数据的数据表面工具比编写自己的代码要快得多。但是你确实在 SP 模型中失去了很多控制权。
使用 BDC 失去很多控制和 $。也许如果 BDC 是免费的或 SP 的标准部分，它会更有说服力。总而言之，为 Excel Services 收费是没有意义的（它们不是很好）。我真的很喜欢 SharePoint 搜索处理 BDC 数据的方式。为此向微软 +1。

【解决方案3】：

SharePoint 应该用作业务用户协作（即存储、查找和编辑彼此的文档）的基础。仅将 SharePoint 用于应用程序开发会造成伤害，并且需要在问题中提出第 3 点。

对于应用程序开发，我更喜欢将 SharePoint 用作将用户指向应用程序或托管其 Web 界面（通过用户控件、Web 部件等）的 Web 门户（哦等等，我已经准备好说 SharePoint 是一个 Web 门户)。

【讨论】：

我想这意味着我们有点同意。我确实喜欢开箱即用的想法，但对于自定义开发，您确实需要专家和策略。
+1 在主机点上。就个人而言，我是 SharePoint 开发的“iframe 模型”的忠实粉丝。

【解决方案4】：

即使没有文档，您仍然可以将 Sharepoint 用作具有自定义 Web 部件（可能其中一些基于站点文档库）的门户平台。这是一个很好的门户平台，我公司的研究门户是基于共享点的，而且效果很好。好消息是，使用这些基于 webpart 的 sharepoint 门户，您仍然可以相对轻松地处理许可问题和演示自定义问题（将 webpart 拖到特定区域等，用户经常这样做，顺便说一句）。此外，WSRP 类型的 webparts 与 Sharepoint 配合得很好。

您是对的，只有当您拥有优秀的 Sharepoint 开发人员时，它才会让您的工作变得轻松，并且是一个体面的平台，有文档或没有文档。

【讨论】：