SharePoint列表在基于SOA的企业中是否有害？

我的公司正在从客户机/服务器应用程序（直接调用数据库的厚客户机应用程序）转向面向服务的体系结构（SOA）（调用web服务然后执行业务逻辑并调用数据库的瘦客户机或厚客户机）

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

SharePoint列表似乎是SharePoint的核心部分。然而，从架构上讲，它们似乎也是一个巨大的倒退。以下是我关注的问题：

• 使用这些列表，我将让我的SharePoint Web部件再次直接访问数据（与我们使用两层客户端/服务器应用时的情况非常相似）
• 这大大混淆了数据层。我是否将客户端列表存储在SQL Server数据库中？还是SharePoint列表？或者两者都有？（说不是这样！）如果两者都存在，我如何保持它们的同步
• 如果我将数据存储在SharePoint列表中，那么我是否必须让我的Web服务使用SharePoint客户端对象模型来获取列表（对于非SharePoint客户端）

基本上，SharePoint列表似乎是一个非常糟糕的主意。但我听说这是SharePoint的一大好处。（尽管我知道资源管理和权限在SharePoint中也很有用。）

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

---

下面是我的问题：我为什么要在访问SQL Server的web服务上使用SharePoint列表的正确/最佳实践原因是什么？SharePoint甚至可以正常使用web服务获取和更新数据吗？（基本上，如果我不使用列表，我会失去很多功能吗？

你是部分正确的。关于您的选择，以下是您应该走的路线：

您应该只在列表中存储数据。不在SQL server中。列表中的数据最终存储在SQL server中的SharePoint内容数据库中，同步它没有意义

要让您的客户端访问数据，您的web服务可以调用SharePoint中公开的现成web服务，该服务可以对数据列表进行操作

请参阅这篇关于SharePoint公开的web服务概述的文章：

---

http://www.sharepointmonitor.com/2007/01/sharepoint-web-service/

SharePoint列表不是一个一刀切的数据存储解决方案。在很多情况下，您都希望使用SharePoint内部的外部系统（如现有CRM数据库）提供的数据

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

SharePoint 2010通过Business Connectivity Services极大地扩展了SharePoint 2007的功能，允许从SharePoint列表进行完全读/写操作，通过API访问，可以在代码中为您试图访问的任何后端系统实现自定义连接器（SQL Server提供了现成的提供程序）。这是关于BCS的入门，还有更多关于MSDN的信息

---

不要试图将SharePoint列表用作RDBMS中的传统表，这不是它们的目的，而且这只会导致今后的严重头痛。

虽然我同意恋母癖的回答，但我觉得你的问题“我为什么要使用列表”需要更详细的回答

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

您没有使用UI，并且可能对SQL非常满意，因此SQL应该是您的选择。在SharePoint中，没有什么事情是SQL无法做到的（通常更快），但SQL对于非技术人员来说设置起来并不那么友好。SharePoint不像SQL那样是一个“完整的数据管理解决方案”，它更像是一个类固醇上的ASP.NET，它有不同的优势。（这就是为什么它的后端是……SQL）

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

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

---

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

这是SharePoint新手面临的一个大问题—我应该将X存储在SharePoint列表中，还是存储在SQL Server表中

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

SharePoint列表当然应该被视为一种存储机制，即使是f