我参与了一个以数据为中心的 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 部件应具有多个键供客户端搜索。我们使用表单 Web 部件和 SPD 来做到这一点没有问题。但真正的问题是如何搜索不在当前列表中的相关字段。 （因此，在这种情况下，我们必须将这些字段值保存在列表中才能进行搜索（废话，我知道！！））。您可能会问，为什么不为此类任务实现 ASP.Net 用户控件？好吧，这需要我们放弃默认的 AllItems Web 部件，并且已经自定义了数百个 AllItems.aspx 页面，其中包含大量自定义内容，这将花费我们大量时间从一开始就重新实现它们。另外，即使我们使用用户控件，CAML 从多个相关列表检索数据的效率也非常低！
2-我想你可以猜到这一点，如果我们已经在搜索 Web 部件方面遇到了很大的困难，那么到底如何才能完成 350 份报告！！:D 但我们找到了一种解决方法（像往常一样） :S) 我们创建了一个 Access DB 文件，其中包含所有 500 个共享点列表的链接，然后我们实现了一个具有报表查看器控件的用户控件。该用户控件采用普通的 T-SQL 查询来查询 Access DB，Access DB 从 SharePoint DB 检索数据并将其传递回用户控件，该用户控件在报表查看器上查看数据集。
还有其他与管理相关的问题，但我想重点关注这里的开发。
所以，在我向你展示了图片之后（很抱歉这篇文章很长）。您认为在这样一个以数据为中心的项目中我们应该采用的最佳 SharePoint 开发技术是什么（如果有的话）？
我听说有些公司在此类项目中根本不使用列表，而是构建自己的 SQL 数据库表而不是 SharePoint 数据库。但我忍不住想知道，如果我制作自己的数据库，从而从头开始实现我的 CRUD Web 部件（我们还将失去 SP 列表提供的安全模块优势），那么会有什么好处共享点？
我再次为这么长的帖子道歉。
I was involved in a SharePoint(WSS) project that was very data centric. The project consisted of more than 500 lists that has very complex relations between them. The client also asked for more than 350 Reports. Don't tell me why did you use SharePoint from the beginning. It was a managerial decision and we already delivered the project after 14 months of pain (this is 6 months overdue to the deadline)
When we first started the project, we didn't know anything about SharePoint development (believe it or not). The management said that they will take the risk. They were very convinced that SharePoint is the optimal solution for anything!!!(well, that proved wrong at the end of the project).
Anyway, we were learning SharePoint while we were developing. Our development were mainly based on SharePoint designer to customize all the AllItems/NewForm/EditForm/DispForm for every list to provide the needed logic/validation that the client asked for (Using JavaScript). We also implemented around 15 Custom Fields (e.g. master-details fields). We also made an event receiver to handle all the adding/updating/deleting... events for all the lists in the site. Plus around 40 ASP.Net user controls.
The main problems that faced us (we worked-around it but sadly in an inefficient way)
1- The Client asked for a search web part in each AllItems.aspx. The search web part should have multiple keys for the client to search with. We did that using Form Web parts using SPD no problem. But the real problem was how to search for a related field that was not in the current list. (So, in such cases we had to save these fields values in our list to be able to search for (crap, I know!!)). You might ask, why didn't you implement ASP.Net user controls for such task? Well, that would require us to forsake the default AllItems web part, and were already customized hundereds of AllItems.aspx pages with alot of customization that would take us a lot of time to reimplement them from the beginnging. Also, even if we used user controls, CAML is very inefficient in retrieving data from multiple related lists!
2- I think you can guess this one, if we've already faced a big time doing search web parts, how on earth will be able to do the 350 reports!!:D But we figured out a work-around (as usual :S) we made an Access DB file with links to all the 500 sharePoint lists, then we implemented a user control that has a report viewer control. This user controls takes an ordinary T-SQL Query to query on the Access DB, the Access DB retrieves the data from the SharePoint DB and pass it back to the user control which views the DataSet on the report viewer.
There are other administration related problems, but I would like to focus on the development here.
So, after I showed you the picture (sorry for the long post). What do you think was the best SharePoint development technique that we should have taken in such a data centric Project, if any?
I heard that some companies doesn't use lists at all in such projects, and builds there own SQL database tables instead of the SharePoint Database. But I can't keep my self from wondering, If I'm making my own DB, and hence implementing my CRUD web parts from scratch (We will also lose the security module benefits provided by SP Lists), what would be the benefits of SharePoint?
Once again I apologize for the long post.
发布评论
评论（4）
我想你已经清楚我做了什么。 Sharepoint 不擅长处理大型企业类型应用程序。我们最终创建了一个自定义数据库来存储我们的数据。我们使用 Webparts 作为用户界面，但除此之外，整个应用程序独立于 Sharepoint。
在我看来，微软夸大了 Sharepoint。它实际上擅长团队协作网站和简单的 Excel 服务应用程序，但它无法处理除此之外的任何事情。
I think you found out exactly what I did. Sharepoint just isn't good at handling large enterprise type applications. We ended up creating a custom database to house our data. We used Webparts for the user interface, but otherwise, the entire application was independent of Sharepoint.
In my opinion, Microsoft is overselling Sharepoint. It's actually good at team collaboration sites and simple Excel services applications, but anything beyond that it just isn't capable of handling.
我不同意 Geoff 和 Abu 的观点，认为 SharePoint 对于大型企业应用程序来说是一个糟糕的选择。
正如您所说，Abu 您的团队正在工作中学习，因为您没有 SharePoint 开发经验，您面临的问题更多的是管理错误而不是平台问题，管理层应该引入 SharePoint 承包商与您的团队一起工作，以帮助构建什么听起来是一个相当复杂的系统。
作为一名使用 SharePoint 多年的开发人员，我参与过的许多项目在我在这个平台上开发的最初几年中，我自己都认为不适合 SharePoint，但是现在有了更多的经验，我认为这些项目不适合 SharePoint。我知道如何更好地利用该平台的力量，并且我意识到使用 SharePoint 来开展此类性质的项目所获得的优势。也就是说，我对该平台的某些部分存在许多问题，但这与我工作过的任何其他平台（包括 ASP.Net 平台的部分）没有什么不同。
如果我被要求使用基于 Java 的定制系统（或者可能是新的 MVC 平台）开发一个解决方案，我确信我会遇到许多与您所经历的类似的问题，但我根本不知道正确的方法是什么。这无论如何都不是平台的问题，但更多的是我的经验不足。
我很遗憾得知你们俩在 SharePoint 平台范围内工作时经历了管理层强加给你们的痛苦。尽管我很失望你们这么快就将责任归咎于你们自己和你们的管理层。
我不能说 SharePoint 是否是您项目的最佳平台，但这并不意味着它对于企业应用程序而言是一个糟糕的平台。
I have to disagree with both Geoff and Abu in regards to SharePoint being a bad choice for large enterprise applications.
As you state yourself Abu your team were learning on the job as you had no SharePoint development experience, the issues you faced was more a Management error that a platform problem, management should have brought in SharePoint contractors to work alongside your team to help build what sounds to be a fairly complex system.
As a developer who has worked with SharePoint for a number of years many of the projects I have worked on some that I myself would not have believed suitable for SharePoint with in my first few years of developing on this platform, however now with more experience I know how to leverage the power of the platform far better and I realise the advantages gained using SharePoint for projects of that nature. That said I have a number of issues with parts of the platform but this is no different to any other platform I have worked on including parts of the ASP.Net platform.
If I was asked to develop a solution using a bespoke Java based system (or perhaps the new MVC platform) I am sure I would experience many problems similar to what you experienced where I simply don’t know what the right approach would be. That would not in any way be an issue with the platform but more with my inexperience.
I am sorry to hear that both of you experienced pains working within the bounds of the SharePoint platform that was forced on you by your management. Though I am disappointed that you are so fast to point the blame away from yourselves and your management.
Was SharePoint the best platform for your projects I can’t say, but that doesn’t make it a bad platform for enterprise applications.
我不同意 Geoff 的观点，即 SharePoint 不适合大型企业类型应用程序。您必须从一开始就记住 SharePoint 是一个开发平台。这意味着它为您提供了许多开箱即用的功能，但高度可定制。
作为一个平台并不意味着每一点自定义都需要基于 SharePoint 列表来完成。由于它是基于 ASP.NET 构建的，因此您可以在 SharePoint 中执行任何在 ASP.NET 中可以执行的操作。
我已经构建了大量托管在 SharePoint 中的 ASP.NET 应用程序，让 SharePoint 进行身份验证等。
但我不得不说，确定 SharePoint 应该停止作为您的基础并且您应该切换到常规 ASP.NET 有时很困难..
I disagree with Geoff that SharePoint is no good for large enterprise type apps. You have to remember from the start that SharePoint is a development PLATFORM. This means it gives tyou a lot of functionality out of the box, but is extremely customisable.
Being a platform does not mean every bit of customisation needs to be done based on SharePoint lists. Seeing as it is built on ASP.NET you can do anything in SharePoint you could do in ASP.NET as well.
I have built a great deal of ASP.NET apps that were hosted in SharePoint, letting SharePoint do the authentication etc.
I have to say though, determining where SharePoint should stop being your base and you should switch to regular ASP.NET is sometimes hard..
如果您正在 SharePoint 中寻找以数据为中心的解决方案，最好的解决方案是使用业务数据目录 (BDC)。这可以将您丰富的数据关系和所有 SQL（或其他 DBMS）优点保留在您想要的位置 - 在一个设计为最适合存储数据的存储库中。
有关 BDC 功能功能的概述，请参阅 SharePoint 杂志上的系列。请注意，这些功能需要 SharePoint 2007 的企业许可证。
If you are looking for a data-centric solution in SharePoint, the best solution is to use the Business Data Catalog (BDC). This keeps your rich data relationships and all of the SQL (or other DBMS) goodness you want where it should be - in a repository designed to be optimal at storing data.
For an overview of what the BDC functionality can do, see this post on the SharePoint Team Blog. For much more details, read the series on SharePoint Magazine. Note that these features requires an Enterprise license of SharePoint 2007.