WSS 3.0作为应用平台
这是一个架构问题。
我们正在构建一个具有基本工作流程的文档管理站点，该站点需要面向外部。面向外部的应用程序需要品牌化，并且应该具有上传和下载文档的功能，并且还支持版本控制。我们决定使用 WSS 3.0 作为协作工具，因为它具有我们需要的所有功能。我们计划通过为每个客户定制品牌来支持多个客户。
我的问题是，我们应该将 WSS 暴露给客户端以面向外部，还是在应用程序层中使用 WSS 构建标准 ASP.NET 应用程序，并让 ASP.NET 应用程序使用 WSS API/Web 服务与 WSS 交互。这使得自定义 ASP.NET 应用程序，而无需对 WSS 进行任何更改。内部用户不需要任何品牌，因此可以访问面向内部的 WSS 站点来执行工作流活动。自从我开始 WSS 开发以来，构建功能和打造品牌一直是一个挑战。
请让我知道您的想法。
This is an architectural question.
We are in the process of building a document management site with basic workflow which needs to be external facing.The external facing application needs to be branded and should have the capability to upload and download documents and also support versioning.We have decided to use WSS 3.0 as the collaboration tool as it has all the features we need.We are planning to support multiple clients with custom branding for each client.
My question is should we expose WSS to the client for external facing or build a standard ASP.NET application using WSS in the application tier and let the ASP.NET app interact with WSS using the WSS API/Web service.This makes it easy to customize the ASP.NET application without having to make any changes to the WSS.The internal users doesnt need any branding and hence could go to the internal facing WSS site to do workflow activities. Building features and getting to brand has been a challenge since I started WSS development.
Please let me know your thoughts.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
SharePoint 很大。真的很大。因此，如果您计划在客户和 SharePoint 之间开发一个自制的中间层，请准备好做大量工作，除非您计划只公开 SharePoint 界面的一小部分。
我建议公开 WSS，并通过创建仅满足 SharePoint 无法满足的要求的 Web 部件、页面和列表，在 WSS 框架内（而不是毗邻）构建应用程序。这应该可以将您的工作量减少到可管理的程度。
查看 VSeWSS 或 WSPBuilder 等工具来简化 WSS 3.0 开发（如果您使用 Visual Studio），并在适当的情况下利用 SharePoint Designer。
SharePoint is big. Really big. As a result, if you plan to develop a home-brewed middle layer between your customers and SharePoint, be prepared to do a lot of work unless you plan only to expose a tiny piece of the SharePoint interface.
I recommend exposing WSS, and building your application within, instead of adjacent to, the WSS framework by creating Web Parts, pages, and lists that meet the requirements SharePoint alone cannot. This should reduce your workload to something manageable.
Take a look at tools such as VSeWSS or WSPBuilder to ease your WSS 3.0 development (should you use Visual Studio), and take advantage of SharePoint Designer where it is appropriate.
如果您对 SharePoint 了解不多，创建和公开 UI 将会很困难。你能做到吗？绝对地。你应该这样做吗？这取决于您的要求以及您对 SharePoint 的专业知识水平。在我看来，最简单的方法是创建一个 ASP.NET 应用程序并与 SharePoint 进行交互，但我每天 90% 的时间都在使用 ASP.NET，并且每年大约只进行一次 SharePoint 开发。
根据我的经验，如果您必须问是否应该使用某种工具构建新产品等，答案通常是知道的。如果我自己无法通过查看该工具来回答这个问题，我会尽量不在大型项目中使用它，因为这意味着，我对它的了解不够深，无法在出现意外情况时摆脱束缚。出现。
If you don't know a lot about SharePoint, creating and exposing a UI is going to be difficult. Can you do it? Absolutely. Should you do it? That depends on your requirements, and your level of expertise with SharePoint. In my opinion, the easiest path would be to create an ASP.NET application and have that interface with SharePoint, but I spend 90% of my day working with ASP.NET and only do SharePoint development about once a year.
In my experience, if you have to ask whether or not you should build a new product etc. with some tool, the answer is generally know. If I can't answer it myself with maybe some looking around on the tool, I try not to use it on a major project, because that means, that I don't know it well enough to get myself out of bind when something unexpected arises.
如果您在下面的 WSS 上进行自定义外套，那么您实际上是在编写该平台（尤其是 SharePoint）已经附带的代码。我认为价格是您决策的一个因素，否则您不会单独使用 WSS。在这种情况下，利用 WSS 作为代码层可能很诱人，但我预计要使其顺利工作将极其困难。
根据您的业务模型，我将了解托管 SharePoint 解决方案可以做什么，特别是如果您可以在其平台上托管自定义 SharePoint 网站定义。
需要非常强大的 IP 或财务要求才能让我考虑将 asp.net 封装在 WSS 之上。
我已经使用了一个解决方案来做到这一点，它确实适用于我们面向外部的站点，但它是一个维护“母马”。
If you do a custom coat over WSS underneath, you are essentially writing code that already comes with the platform, especially with SharePoint. I assume that price is a factor in your decision making or you would not use WSS alone. In that case it can be tempting to leverage WSS as a code layer, but I would expect that it would be extremely difficult to make that work smoothly.
Depending on your business model I would look at what hosted SharePoint solutions can do, especially if you can host a custom SharePoint site definition on their platform.
It would take a very strong IP or financial requirement to make me consider wrapping asp.net over top of WSS.
I have worked with a solution that does that and it does work for our externally facing site, but it is a maintenance 'mare.