到SharePoint或不（作为应用程序开发的基础）（与ASP.NET）

Question

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

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

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

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

那你觉得怎么样？

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

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

Answer 1

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

Answer 2

假设您有一个数据仓库，可以从公司的许多点收集数据。希望您有一些维度，将业务人员指定为“维度所有者”。这些人与维度中的数据组织有利害关系。他们负责保持层次结构和列表的最新状态，但这些集合不包含来自事务系统的操作数据，它们是业务术语，组和业务所说的描述。这是他们的自然商业语言。东部销售团队，小型企业，高风险，平面广告促销25等等。关键是您的数据仓库是由99％的运营/交易内容构建的，但是这些业务安排使您的用户感到理智并且您需要抓住它的地方。

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

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

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

Answer 3

SharePoint应该用作业务用户协作的基础（即存储，查找和编辑其他文档）。仅使用SharePoint进行应用程序开发会受到伤害，并且需要在问题中提出第3点。

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

Answer 4

即使没有文档，您仍然可以使用Sharepoint作为具有自定义Web部件的门户的平台（可能其中一些基于站点文档库）。它是一个很好的门户平台，我的公司研究门户网站是基于sharepoint的，它运作良好。好处是，使用这些基于webparts的sharepoint门户网站，您仍然可以相对轻松地处理权限问题和演示文稿自定义问题（将webpart拖动到特定区域等，用户可以做很多事情，顺便说一下）。此外，WSRP类型的webparts与Sharepoint的效果非常好。

你是对的，只有你拥有优秀的Sharepoint开发者，那么它确实让你感觉轻松，并且是一个不错的平台，文档或没有文档。