何时使用SharePoint中的Web Part而不是完整的ASP.NET应用程序？

Question

由于我正在从ASP.NET Web Forms转向SharePoint，因此我仍在努力解决这个问题。我们希望出于多种原因专门使用SharePoint；其中一个主要卖点是为了 conslidate 我们的开发工作。例如，今天我们有几个单独的网站，每个网站有1-5个页面（较小），分布在几台服务器、IIS安装程序等上。

假设我需要一个小型网站（1-5个页面）。在SharePoint中处理这种情况的方法是什么？我是创建几个Web Part，然后在SharePoint中创建页面并将它们插入其中，还是只需创建一个ASP.NET Web Forms应用程序，并在SharePoint中提供链接即可？

谢谢！

更新

我两者都不选。根据反馈和额外的研究，似乎应该使用Application pages。以下是一篇好文章：http://grounding.co.za/blogs/brett/archive/2008/07/13/sharepoint-the-role-of-a-web-part-vs-using-application-pages.aspx

- Mike

Answer 1

当你希望非技术用户能够通过SharePoint UI组合页面时，你可以使用SharePoint Web部件——在站点中创建新页面、选择所需部件、配置它们并将它们排列在页面上。他们可以使用受众定位来仅向特定用户显示所需的Web部件。

使用SharePoint，你基本上可以获得所有这些功能。即使你一开始不需要全部，与构建普通的ASP.NET应用程序相比，它也不需要更多的努力，除了克服初始学习曲线。

- Rex M

Answer 2

不要着急创建asp.net web应用程序与Sharepoint交互，使用共享工作区有很多开箱即用的功能可以完成。 如果这还不够，你可以轻松编程Sharepoint 2010。你可以创建应用程序页面，这些页面相当于ASP.NET Web表单。在创建两个独立系统之前，请优先考虑这一点。

这些页面的作用是什么？

- Karel

---

这是一个定制的数据库。它包含人员、位置等信息，有许多不同的业务规则。 - Mike

我应该说，我认为现成的解决方案在这里行不通。由于时间紧迫，我必须尽力利用我的ASP.NET技能来完成这个第一个项目，并在实践中学习。那么，我是使用多个Web部件创建此项目还是使用标准的ASP.NET应用程序呢？ - Mike

我们使用SharePoint应用程序页面创建了一个“定制数据库解决方案”，并连接到SQL Server（遗留）数据库。一旦掌握了技巧，它就像标准的ASP.NET一样容易；并且已经集成。 - Karel

是的，这就是我要走的路——为定制解决方案创建应用程序页面。现在我只需要研究安全性，因为它们对所有站点都是开放的。 - Mike

Answer 3

这是我们所做的...我们将所有现有的应用程序移动到了一个专用的应用程序站点上。这样做的想法是为了让我们能够更快地推出SharePoint。我们开发了一个定制的Web Part，其中包含新应用程序站点上所有部门应用程序的安全修剪链接。唯一部署的解决方案是用于自定义。

这样做的想法是，只有在真正需要的情况下，我们才能继续前进并将现有应用程序移植过来。所有基于协作的新应用程序都可以根据需要从头开始在SharePoint上开发。

更新

您可以创建应用程序页面，但要熟悉应用程序页面和站点页面之间的区别：

http://blogs.msdn.com/b/kaevans/archive/2010/06/28/creating-a-sharepoint-site-page-with-code-behind-using-visual-studio-2010.aspx

- IrishChieftain

---

如果时间不是问题，根据您的专业意见，您认为最好使用Web Parts来创建这些应用程序吗？如果我的应用程序有5个页面，其中包含多个网格、文本框、按钮等等...将它们转换为单独的Web Parts是否符合"SharePoint感觉"？那么我将拥有查看人员Web Part、查看位置Web Part、数据输入人员Web Part等。 - Mike

如果是一个发布站点，我会将我的ASP.NET应用程序分离到一个单独的站点/服务器，并将前端设计与SharePoint相匹配。如果只是普通的WSS，则更加麻烦和可能不必要。 - IrishChieftain

Answer 4

你在寻找什么样的用户体验？有时候创建一个静态页面很有意义，而有时候让用户移动元素和创建自己的页面会更好。创建Web部件并不太难，但我看到你时间比较紧，初学阶段可能需要一点时间来克服难点。

对于我来说很难估计学习曲线，因为Visual Studio 2010比我刚开始接触SharePoint时可用的任何工具都更容易操作。

- coder1

---

我想我不太担心学习曲线。我已经研究了几周的Web Parts，我认为这不会太难。我觉得我的问题是我不知道这是否是SharePoint完成它的方式？所以说这个项目有5个ASP.NET页面。那可能等于10个Web Parts。这是Web Parts的目的，还是用于更专注的开发，如日历、公告等？我只是不确定Web Parts是否应该以这种方式使用。这是我的问题和主要关注点。谢谢。 - Mike

我们尽量保持大多数网络部件的范围相对较小。大多数我们的网络部件只做一两件事情，不适合作为独立页面。这并不是说你不能将整个页面的功能和特性放入一个网络部件中，但我认为我更倾向于让它们更小。 - coder1

是的，抱歉，我的意思不是要尝试将一个页面适应一个网络部件。例如，假设我有一个ASP.NET网页。该页面具有输入新人员的表单和查看和搜索的网格。现在，如果我按照SharePoint的方式进行操作，我会创建两个网络部件 - 数据输入人员和查看人员。然后我会继续这样将我的ASP.NET应用程序转换为SharePoint。您是否认为这种方法存在问题？谢谢。 - Mike