SharePoint在基于SOA的企业中是否存在恶意？

Question

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

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

SharePoint列表似乎是SharePoint的核心部分。然而，从建筑学的角度来看，它们似乎也是一个巨大的倒退。这些是我的担忧：

• 使用这些列表，我将让我的SharePoint Web部件再次直接访问数据（就像我们使用2层客户端/服务器应用程序时那样）。
• 这使数据层混淆了很多时间。我是否将我的客户列表存储在SQL Server数据库中？还是SharePoint列表？或两者？ （说不是这样！）如果两者兼而有之，我如何让它们保持同步？
• 如果我将数据存储在SharePoint列表中，那么我是否必须使用SharePoint客户端对象模型获取Web服务以获取列表（对于非SharePoint客户端）？

基本上，SharePoint列表看起来非常糟糕。但我听到的是，这是SharePoint的一大好处。 （虽然我知道有些资源管理和权限在SharePoint中也很有用。）

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

以下是我的问题：为什么我将SharePoint列表用于访问SQL Server的Web服务的正确/最佳实践原因是什么？并且SharePoint甚至可以使用Web服务正常工作并更新数据？ （基本上，如果我不使用列表，我会丢失很多功能吗？）

Answer 1

SharePoint列表不是一种适合所有数据存储的解决方案。在很多场景中，您都希望使用外部系统提供的数据，例如SharePoint内部的现有CRM数据库。

SharePoint 2007使用了一个名为Business Data Catalog的概念来解决其中一些场景，允许在SharePoint列表中使用只读的外部系统数据视图。

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

要小心尝试将SharePoint列表用作RDBMS中的传统表，这些不是它们的目的，它只会导致紧张的问题。

Answer 2

虽然我同意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），而不会使应用程序依赖于它

Answer 3

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

您应该只将数据存储在列表中。不在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/

Answer 4

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

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

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

警告：绝不想直接与SharePoint内容数据库进行交互。