WSS 3.0作为应用程序平台

Question

这是一个架构问题。

我们正在构建一个基本工作流程需要面向外部的文档管理站点。面向外部的应用程序需要打上标签，应该具有上传和下载文档的能力，并且还支持版本控制。我们已经决定使用WSS 3.0作为协作工具，因为它具有我们需要的所有功能。我们计划为每个客户提供自定义品牌支持的多个客户。

我的问题是我们应该将WSS暴露给客户端以便面向外部，还是应用程序层中使用WSS构建标准ASP.NET应用程序，并让ASP.NET应用程序使用WSS API / Web服务与WSS交互。这使得它可以轻松自定义ASP.NET应用程序，而无需对WSS进行任何更改。内部用户不需要任何品牌，因此可以转到面向内部的WSS站点来执行工作流活动。自从我开始开发WSS以来，构建功能和获得品牌一直是一个挑战。

请让我知道你的想法。

Answer 1

SharePoint很棒。真的很大。因此，如果您计划在客户和SharePoint之间开发自制的中间层，请准备好做很多工作，除非您只打算展示一小部分SharePoint界面。

我建议公开WSS，并通过创建满足SharePoint单独不能满足的要求的Web部件，页面和列表，在WSS框架内构建应用程序，而不是在其附近构建应用程序。这可以将您的工作量减少到可管理的程度。

查看VSeWSS或WSPBuilder等工具以简化您的WSS 3.0开发（如果您使用Visual Studio），并在适当的地方利用SharePoint Designer。

Answer 2

如果您对SharePoint了解不多，那么创建和公开UI将很困难。你可以做到吗？绝对。你应该这样做吗？这取决于您的要求以及您对SharePoint的专业水平。在我看来，最简单的方法是创建一个ASP.NET应用程序并与SharePoint建立该接口，但我每天花90％的时间使用ASP.NET，并且每年只进行一次SharePoint开发。

根据我的经验，如果您不得不询问是否应该使用某种工具制作新产品等，那么答案通常都是知道的。如果我自己也不能回答这个问题，我可能会在一个重大的项目中使用它，因为这意味着，当我意外的事情发生时我不能很好地理解它就产生了。

Answer 3

如果你在WSS下面做一个自定义外套，你实际上是在编写平台已经附带的代码，特别是在SharePoint中。我认为价格是决策的一个因素，或者你不会单独使用WSS。在这种情况下，将WSS用作代码层可能很有吸引力，但我希望能够顺利地完成这项工作是非常困难的。

根据您的业务模型，我会查看托管SharePoint解决方案可以执行的操作，尤其是如果您可以在其平台上托管自定义SharePoint网站定义。

需要非常强大的IP或财务要求才能让我考虑将asp.net包装在WSS之上。

我使用过这样做的解决方案，它确实适用于我们面向外部的网站，但它是一个维护母马。