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

Question

我的公司正在从客户端/服务器应用程序(直接调用数据库的胖客户端应用程序)转向面向服务的架构 (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 服务来获取并更新数据？ (基本上，如果我不使用列表，我会失去很多功能吗？)

Answer 1

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

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

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

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