我参与了一个以数据为中心的 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 查询来查询 Access DB,Access DB 从 SharePoint DB 中检索数据并将其传递回用户控件,该用户控件在报表查看器上查看 DataSet。
还有其他与管理相关的问题,但我想重点关注这里的开发。
所以,在我给你看照片之后(对不起,很长的帖子)。您认为我们在这样一个以数据为中心的项目中应该采用的最佳 SharePoint 开发技术是什么(如果有的话)?
我听说有些公司在此类项目中根本不使用列表,而是在其中构建自己的 SQL 数据库表而不是 SharePoint 数据库。但是我不能不让自己想知道,如果我正在制作自己的数据库,并因此从头开始实现我的 CRUD Web 部件(我们也将失去 SP 列表提供的安全模块优势),那么共享点?
我再次为这篇长文道歉。