这是一个架构问题。
我们正在构建一个具有基本工作流程的文档管理网站，需要面向外部。面向外部的应用程序需要品牌化，并且应该具有上传和下载文档的能力，还支持版本控制。我们决定使用 WSS 3.0 作为协作工具，因为它具有我们需要的所有功能。我们计划通过为每个客户定制品牌来支持多个客户。
我的问题是我们应该向客户端公开 WSS 以面向外部，还是在应用层使用 WSS 构建标准 ASP.NET 应用程序，并让 ASP.NET 应用程序使用 WSS API/Web 服务与 WSS 交互。这使得无需对 WSS 进行任何更改即可轻松自定义 ASP.NET 应用程序。内部用户不需要任何品牌，因此可以前往面向内部的 WSS 站点进行工作流活动。自从我开始 WSS 开发以来，构建功能和获得品牌一直是一个挑战。
请告诉我你的想法。
【问题讨论】：
标签： sharepoint wss wss-3.0
SharePoint 很大。真的很大。因此，如果您计划在您的客户和 SharePoint 之间开发一个自制的中间层，请准备好做大量工作，除非您计划只公开一小部分 SharePoint 界面。
我建议公开 WSS，并通过创建满足 SharePoint 单独无法满足的要求的 Web 部件、页面和列表，在 WSS 框架内而不是与 WSS 框架相邻构建应用程序。这应该会将您的工作量减少到可管理的程度。
查看 VSeWSS 或 WSPBuilder 等工具，以简化您的 WSS 3.0 开发（如果您使用 Visual Studio），并在适当的地方利用 SharePoint Designer。
【讨论】：
如果您对 SharePoint 不太了解，那么创建和公开 UI 将会很困难。你能做到吗？绝对地。你应该这样做吗？这取决于您的要求以及您对 SharePoint 的专业知识水平。在我看来，最简单的方法是创建一个 ASP.NET 应用程序并拥有与 SharePoint 的接口，但我每天 90% 的时间都在使用 ASP.NET，并且每年只进行一次 SharePoint 开发。
根据我的经验，如果您必须询问是否应该使用某些工具构建新产品等，答案通常是知道的。如果我自己无法通过四处查看该工具来回答这个问题，我会尽量不在一个重大项目中使用它，因为这意味着，当出现意外情况时，我对它的了解还不够充分，无法让自己摆脱束缚出现。
【讨论】：
如果您在下面的 WSS 上进行自定义外套，您实际上是在编写平台已经附带的代码，尤其是 SharePoint。我认为价格是您决策的一个因素，否则您不会单独使用 WSS。在这种情况下，将 WSS 用作代码层可能很诱人，但我预计要使其顺利工作会非常困难。
根据您的业务模型，我会看看托管 SharePoint 解决方案可以做什么，特别是如果您可以在他们的平台上托管自定义 SharePoint 网站定义。
需要非常强大的 IP 或财务要求才能让我考虑将 asp.net 包装在 WSS 之上。
我已经使用了一个解决方案，它确实适用于我们面向外部的站点，但它是一个维护“母马”。
【讨论】：