SharePoint 开发和以数据为中心的项目答案

【问题标题】：SharePoint Development and Data Centric ProjectsSharePoint 开发和以数据为中心的项目
【发布时间】：2010-11-23 08:16:23
【问题描述】：

我参与了一个以数据为中心的 SharePoint(WSS) 项目。该项目由 500 多个列表组成，它们之间的关系非常复杂。客户还要求提供 350 多份报告。不要告诉我你为什么从一开始就使用 SharePoint。这是一个管理决定，经过 14 个月的痛苦，我们已经交付了项目（这比截止日期晚了 6 个月）

当我们第一次启动该项目时，我们对 SharePoint 开发一无所知（信不信由你）。管理层表示他们将承担风险。他们坚信 SharePoint 是任何事情的最佳解决方案！！！（嗯，在项目结束时证明是错误的）。

无论如何，我们在开发的同时也在学习 SharePoint。我们的开发主要基于 SharePoint 设计器，为每个列表自定义所有 AllItems/NewForm/EditForm/DispForm，以提供客户要求的所需逻辑/验证（使用 JavaScript）。我们还实现了大约 15 个自定义字段（例如主从字段）。我们还制作了一个事件接收器来处理站点中所有列表的所有添加/更新/删除...事件。加上大约 40 个 ASP.Net 用户控件。

我们面临的主要问题（我们解决了它，但遗憾的是效率低下）

1- 客户端要求在每个 AllItems.aspx 中提供一个搜索 Web 部件。搜索 Web 部件应该有多个键供客户端搜索。我们使用 SPD 的表单 Web 部件做到了这一点，没有问题。但真正的问题是如何搜索不在当前列表中的相关字段。（因此，在这种情况下，我们必须将这些字段值保存在列表中以便能够搜索（废话，我知道！！））。您可能会问，为什么不为此类任务实现 ASP.Net 用户控件？好吧，这将要求我们放弃默认的 AllItems Web 部件，并且已经定制了数百个 AllItems.aspx 页面，并进行了大量自定义，这将花费我们大量时间从一开始就重新实现它们。此外，即使我们使用了用户控件，CAML 在从多个相关列表中检索数据时效率也非常低！

2- 我想你可以猜到这一点，如果我们已经在搜索 web 部件方面遇到了很大的困难，那么到底如何才能完成 350 份报告！！：D 但我们想出了一个解决方法（像往常一样：S）我们制作了一个 Access DB 文件，其中包含指向所有 500 个 sharePoint 列表的链接，然后我们实现了一个具有报表查看器控件的用户控件。该用户控件使用普通的 T-SQL Query 来查询 Access DB，Access DB 从 SharePoint DB 中检索数据并将其传回给在报表查看器上查看 DataSet 的用户控件。

还有其他管理相关的问题，但我想在这里专注于开发。

所以，在我给你看图片之后（对不起，很长的帖子）。您认为我们应该在这样一个以数据为中心的项目中采用的最佳 SharePoint 开发技术是什么（如果有的话）？

我听说有些公司在此类项目中根本不使用列表，而是在其中构建自己的 SQL 数据库表而不是 SharePoint 数据库。但是我不能不让自己想知道，如果我正在制作自己的数据库，并因此从头开始实现我的 CRUD Web 部件（我们也将失去 SP 列表提供的安全模块优势），那么共享点？

再次为这篇长文道歉。

【问题讨论】：

标签： asp.net sharepoint sharepoint-designer wss-3.0

【解决方案1】：

我想你确切地知道我做了什么。 Sharepoint 只是不擅长处理大型企业类型的应用程序。我们最终创建了一个自定义数据库来存放我们的数据。我们将 Webparts 用于用户界面，但除此之外，整个应用程序都独立于 Sharepoint。

在我看来，微软在销售 Sharepoint。它实际上擅长团队协作站点和简单的 Excel 服务应用程序，但除此之外的任何事情它都无法处理。

【讨论】：

【解决方案2】：

我不同意 Geoff 的观点，即 SharePoint 不适合大型企业类型的应用程序。您必须从一开始就记住 SharePoint 是一个开发平台。这意味着它为您提供了很多开箱即用的功能，而且非常可定制。

作为一个平台并不意味着每一点定制都需要基于 SharePoint 列表来完成。由于它是在 ASP.NET 上构建的，因此您可以在 SharePoint 中执行您在 ASP.NET 中也可以执行的任何操作。

我已经构建了大量托管在 SharePoint 中的 ASP.NET 应用程序，让 SharePoint 进行身份验证等。

但我不得不说，确定 SharePoint 应该在哪里停止成为您的基础并且您应该切换到常规 ASP.NET 有时很难..

【讨论】：

"让 SharePoint 进行身份验证等。"如果您不使用列表，sharePoint 将如何进行身份验证？此外，当 SharePoint 仅托管您的 ASP.Net 用户控件时，除了身份验证之外，它还能提供什么？
假设客户端有一个基于 SharePoint 的 Intranet，只需将您的应用程序托管在那里（子网站或网站集）。您仍然可以使用列表作为参考，但不能）。
我不确定我是否理解，科林。如果我正在制作连接到我创建的 SQL DB 表的 ASP.Net 用户控件，我怎样才能在托管 SharePoint 网站上仍然使用列表作为参考？你能解释更多吗。谢谢
我的意思是说数据可以来自任何地方。它可以在 SQL 中，也可以在 SharePoint 列表中。假设您在 SharePoint 中有一个包含商店位置的列表。您可以使用 SQL 存储有关这些商店的更多数据（销售等）
也许我的观点受到了我使用 Sharepoint 的经验的影响。我希望看到使用尽可能多的开箱即用共享点构建的大型应用程序。需要克服的问题：跨浏览器功能、连接来自多个列表的查询等。

【解决方案3】：

如果您在 SharePoint 中寻找以数据为中心的解决方案，最好的解决方案是使用 业务数据目录 (BDC)。这样可以将您丰富的数据关系和所有您想要的 SQL（或其他 DBMS）优点保留在应有的位置 - 设计用于存储数据的最佳存储库。

有关 BDC 功能可以做什么的概述，请参阅 SharePoint 团队博客上的 this post。有关更多详细信息，请阅读the series on SharePoint Magazine。请注意，这些功能需要 SharePoint 2007 的企业许可证。

【讨论】：

【解决方案4】：

我不同意 Geoff 和 Abu 关于 SharePoint 是大型企业应用程序的错误选择的观点。

您自称 Abu，您的团队正在工作中学习，因为您没有 SharePoint 开发经验，您面临的问题更多是管理错误而不是平台问题，管理层应该让 SharePoint 承包商与您的团队一起工作帮助构建听起来相当复杂的系统。

作为一名使用 SharePoint 多年的开发人员，我曾参与过一些我自己在最初几年在此平台上进行开发时并不认为适合 SharePoint 的项目，但现在有了更多经验我知道如何更好地利用平台的力量，并且意识到使用 SharePoint 进行此类项目所获得的优势。这就是说我在平台的某些部分方面存在许多问题，但这与我从事过的任何其他平台（包括 ASP.Net 平台的某些部分）没有什么不同。

如果我被要求使用基于 Java 的定制系统（或者可能是新的 MVC 平台）开发解决方案，我相信我会遇到许多与您遇到的类似的问题，我根本不知道什么是正确的方法是。这绝不是平台的问题，但更多的是我的经验不足。

得知你们俩都在管理层强加于您的 SharePoint 平台范围内工作时，我感到很遗憾。虽然我很失望你这么快就将责任从你自己和你的管理层身上移开。

我不能说 SharePoint 是否是您项目的最佳平台，但这并不意味着它对于企业应用程序来说是一个糟糕的平台。

【讨论】：

我的回答有点含糊，但我想说的是请专家，你有一个复杂的系统和复杂的要求，SharePoint 可以非常擅长这个，但如果做错了，它将是一个噩梦。
我还没有看到使用 SharePoint 构建的大型应用程序的示例。 SharePoint 平台提供了什么使应用程序的开发更简单、更快、更易于维护等？
SharePoint 没有添加任何您无法在其他地方获得的东西，而且比其他平台更适合您想要的个人应用程序。然而，SharePoint 提供的是多个应用程序的通用基础，其中每个应用程序处理单独的任务。这导致了跨所有企业应用程序的通用用户体验、用于应用程序管理的通用后端平台、通用管理界面，此外许多用户可以创建自己的小型无代码应用程序。 SharePoint 在深度上失去的是广度。它是万事通，但无一精通