SharePoint 列表在基于 SOA 的企业中是邪恶的吗？答案

【问题标题】：Are SharePoint Lists evil in an SOA based enterprise?SharePoint 列表在基于 SOA 的企业中是邪恶的吗？
【发布时间】：2011-06-01 09:43:38
【问题描述】：

我的公司正在从客户端/服务器应用程序（直接调用数据库的胖客户端应用程序）转向面向服务的架构 (SOA)（调用 Web 服务的瘦客户端或胖客户端，然后执行业务逻辑并调用数据库） .

其中一部分包括使用 SharePoint 作为我们的客户端（不是我们唯一的客户端类型，而是主要的客户端类型）。我一直在观看关于 SharePoint 的 Pluralsight 培训，并且开始看到很多关于 SharePoint 列表的信息。

SharePoint 列表似乎是 SharePoint 的核心部分。然而，从架构上讲，它们似乎也是一个巨大的倒退。这些是我的担忧：

使用这些列表，我将让我的 SharePoint Webpart 再次直接访问数据（就像我们使用 2 层客户端/服务器应用程序时一样）。
这很容易混淆数据层。我是否将我的客户端列表存储在 SQL Server 数据库中？还是 SharePoint 列表？或两者？（说不是这样！）如果两者都是，我如何让它们保持同步？
如果我将数据存储在 SharePoint 列表中，我是否必须让我的 Web 服务使用 SharePoint 客户端对象模型才能访问列表（对于非 SharePoint 客户端）？

基本上，SharePoint 列表似乎是一个非常非常糟糕的主意。但我听到的是，它是 SharePoint 的一大优势。（虽然我知道资源管理和权限之类的东西在 SharePoint 中也很有用。）

SharePoint 列表似乎是一种低等级数据存储的尝试。（没有像 SQL Server 这样的完整数据管理解决方案的所有好处。）

以下是我的问题：我为什么要使用 SharePoint 列表而不是访问 SQL Server 的 Web 服务？ 并且 SharePoint 甚至可以正常工作，使用 Web 服务来获取并更新数据？（基本上，如果我不使用列表，我会失去很多功能吗？）

【问题讨论】：

标签： sharepoint sql-server-2008 sharepoint-2010

【解决方案1】：

你说对了一部分。关于您的选择，这是您应该走的路线：

您应该只将数据存储在列表中。不在 SQL 服务器中。列表中的数据最终存储在 SQL Server 中的 SharePoint 内容数据库中，没有必要进行同步。

为了让您的客户访问数据，您的 Web 服务可以调用 SharePoint 中公开的开箱即用 Web 服务，这些服务可以对列表数据进行操作。

请参阅有关 SharePoint 公开的 Web 服务概述的这篇文章： http://msdn.microsoft.com/en-us/library/ee538665.aspx http://www.sharepointmonitor.com/2007/01/sharepoint-web-service/

【讨论】：

【解决方案2】：

SharePoint 列表并不是一种适合所有数据存储的解决方案。在很多情况下，您都希望在 SharePoint 内部使用来自外部系统（如现有 CRM 数据库）的可用数据。

SharePoint 2007 使用称为业务数据目录的概念来解决其中一些场景，从而允许在 SharePoint 列表中以只读方式查看外部系统数据。

SharePoint 2010 通过 Business Connectivity Services 极大地扩展了 SharePoint 2007 的功能，允许从 SharePoint 列表进行完全读/写，API 访问允许在代码中为您可能尝试访问的任何后端系统（a SQL Server 提供程序是开箱即用的）。这是关于 BCS 的 a pretty thorough 入门，还有更多信息可以在 MSDN 上找到。

在尝试将 SharePoint 列表用作 RDBMS 中的传统表格时要小心，这不是他们的目的，而且只会导致未来的严重头痛。

【讨论】：

看起来我可以将所有“客户端”存储在我的 SQL Server 数据库中，但使用 BCS 在 SharePoint 中将其显示为列表。不是一个完美的解决方案（它仍然是 2 层），但考虑到 SharePoint 的以列表为中心的系统，我能想到的最好的解决方案。感谢您的信息！

【解决方案3】：

虽然我同意 OedipusPrime 的回答，但我认为您的问题“我为什么要使用列表”需要更详细的回答。

简短的版本是，您可能不应该这样做。 SharePoint 为您提供的是有点“类似于数据库”的列表，但足够简单，您的普通用户可以处理它们。它们对用户来说非常灵活。它还为您提供与列表和数据交互的用户界面。

您没有使用 UI，而且您可能对 SQL 很满意，因此 SQL 应该是您的选择。您可以在 SharePoint 中做任何您自己在 SQL 中做不到的事情（通常更快） - 但对于非技术人员进行设置，SQL 对用户来说并不友好。 SharePoint 不像 SQL 那样是“完整的数据管理解决方案”——它更像是 ASP.NET，而且它具有不同的优势。（所以它的后端是……SQL）

那么，您会将数据存储在哪里？ SQL 或列表。一个或另一个 - 不要两者都做，那永远不会奏效。如果您的数据在 SQL 中，您可以使用前面提到的 BCS 在 SharePoint 中公开它。

如果您的数据在 SharePoint 列表中，是的，您可以使用客户端对象模型。或者您可以直接使用 Web 服务。或 REST API。所有这些都是有效的选项。

或者，您可以通过自己的 Web 服务公开数据库中的数据，然后通过 SharePoint 的 BCS 使用这些数据，从而允许您在 SharePoint 中呈现您的数据（如果需要，可以使用完整的 CRUD），而您的应用程序不会依赖它.

【讨论】：

感谢您的进一步澄清。我真的很喜欢你的最后一段，我认为这就是我将尝试引导我的公司的方式。

【解决方案4】：

这是 SharePoint 新用户面临的大问题之一 - 我应该将 X 存储在 SharePoint 列表还是 SQL Server 表中？

SharePoint 列表与数据库表的相似之处在于它们具有行（项目）和列以及触发器（事件接收器）的等效项。数据管理页面是 SharePoint 的一部分，因此无需构建页面来更新和添加项目到表中，此外，列表可以作为 RSS 提要或通过 Web 服务公开。它们还可以进行版本控制并参与工作流程。另一个优点是列表的内容会自动包含在内容备份中，因此无需管理单独的备份和恢复过程——所有内容都在内容数据库中。可能不一定会对性能产生影响，因为有多种缓存机制在发挥作用。

SharePoint 列表当然应该被视为一种存储机制，即使对于经过适当处理的大型数据集也是如此。从某种意义上说，SharePoint 列表充当了一个有效的数据访问层，记住数据最终还是存储在 SQL Server 数据库中。您没有得到的是关系建模、规范化、引用完整性、执行计划优化以及 DBA 手艺的所有其他工具的严谨性。如果数据的有效管理依赖于这些技能，那么将数据直接存储在自己的数据库中可能是更好的选择。您仍然可以通过 BCS 以及自定义代码获取数据。

一句警告：决不要试图直接与 SharePoint 内容数据库进行交互。

【讨论】：