7

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

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

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

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

所以你怎么看？

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

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

4

4 回答 4

5

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

于 2009-07-24T14:22:53.273 回答
3

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

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

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

顺便说一句 - 这是在 SharePoint 列表和 SSIS 之间推送和拉取数据的非常方便的方法。

于 2009-07-24T15:21:31.430 回答
1

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

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

于 2009-07-26T07:30:59.213 回答
0

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

你是对的，只有当你有优秀的 Sharepoint 开发人员时，它才会让你的事情变得简单，并且是一个体面的平台，文档或没有文档。

于 2009-09-01T15:31:22.750 回答