SharePoint 2010 应用程序页面。与 Web 部件

发布于 2024-11-28 09:29:05 字数 1082 浏览 0 评论 0 原文

我对这个问题进行了多次搜索,结果好坏参半,并且随之而来的含糊不清。是时候彻底解决这个问题了。如果我正在开发相当于复杂 ASP.NET 应用程序的内容,并且希望在 SharePoint 2010 之上运行它,那么最好将每个页面开发为 Web 部件还是 ASPX 应用程序页面?这些页面多种多样,但每个页面都通过自定义 WCF 服务与 SQL 2008 R2 后端进行交互。

我还没有看到这个问题的明确和权威的答案。我正在寻找 Microsoft 或类似的官方指南。以下是我迄今为止发现的内容的细分:

以下非官方帖子显然有利于我的案例的申请页面。然而,它是在 MOSS 2007 年发布的,当时 SharePoint 开发更具挑战性。 http://grounding.co.za/blogs/brett/archive/2008/07/13/sharepoint-the-role-of-a-web-part-vs-using-application-pages。 Microsoft

在比较应用程序页面和网站页面时指出,“如果您希望页面包含自定义代码,那么应用程序页面是创建的最佳页面类型。” http://msdn.microsoft.com/en-us/library/ee231581.aspx到目前为止

,一切都很好。但让我失望的是另一个看似矛盾的链接,也来自 MS: “我们目前建议第三方开发人员开发可添加到网站页面的自定义 Web 部件,以便尽可能处理其解决方案的功能,而不是开发自定义应用程序页面。” (msdn.microsoft.com/en-us/library/gg552610.aspx)

我偏向于应用程序页面,因为我们的团队一直在使用该页面并且没有出现任何问题。从开发体验到调试和部署支持,一切都是一流的。但内部力量正在推动我们转向 Web 部件,所以我正在寻找理由。

I have done many a search on this issue with mixed results and ensuing ambiguity. The time has come to nail it down for good. If I'm developing the equivalent of a complex ASP.NET application, and I want to run it on top of SharePoint 2010, is it best to develop each page as a web part or an ASPX application page? The pages are many and varied, but each one interacts with a SQL 2008 R2 backend via custom WCF services.

I have yet to see a definitive and authoritative answer to this question. I'm looking for an official guideline from Microsoft or similar. Here's a breakdown of what I have found so far:

The following non-official post would clearly favor application pages for my case. However, it was posted back in the MOSS 2007 days, when SharePoint development was more of a challenge.
http://grounding.co.za/blogs/brett/archive/2008/07/13/sharepoint-the-role-of-a-web-part-vs-using-application-pages.aspx

Microsoft, in comparing application pages to site pages, states, “An application page is the best type of page to create if you want the page to contain custom code.”
http://msdn.microsoft.com/en-us/library/ee231581.aspx

So far, so good. But what threw me off was this other seemingly contradictory link, also from MS:
"We currently recommend that third-party developers develop custom Web Parts, which can be added to site pages, to handle their solution's functionality whenever possible, rather than develop custom application pages.”
(msdn.microsoft.com/en-us/library/gg552610.aspx)

I'm biased toward application pages because that's what our team has been using all along and has had no problems. Everything from the development experience to debugging and deployment support has been top notch. But internal forces are pushing for us to make the switch to web parts, so I'm looking for justification.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

逐鹿 2024-12-05 09:29:05

这取决于您想要的行为。如果您希望将动态页面中的内容嵌入到 SharePoint 母版页(包含所有导航和样式)中,则可以创建 Web 部件并将 Web 部件附加到 Web 部件页面或任何 SharePoint 页面。如果您的内容页面可以独立存在而无需 SharePoint 导航,则您可以创建应用程序页面。

需要 SharePoint 导航 (UX)?然后创建 Web 部件。
不依赖于 SharePoint 导航?创建应用程序页面。

It depends on what your desired behavior. If you want content from your dynamic pages to be embedded inside the SharePoint master pages (with all the navigation and styling), you would create web parts and attach the web parts to web part pages or any SharePoint page. If your content pages can stand on their own without the need of SharePoint navigation, you can create application pages.

Need SharePoint navigation (UX)? Then create web parts.
Not depended on SharePoint navigation? Create application pages.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文