PnP Core SDK 和 PnP 框架之间的区别

Question

今天读了一篇关于两个PnP库“ PnP Core SDK ”和“PnP Framework”的文章。

\n

PnP Core SDK 似乎是一个完全抽象 SharePoint/Teams 的 CSOM、Graph 或 REST API 的框架。
\n因此，我可以只使用 Pnp-Context，而不必再关心后台是否实际使用 Graph 或 CSOM。
\n这对我来说很有意义。

\n

但 PnP 框架也是一个新库，它仍然提供对实际 CSOM 上下文的访问。
\n这让我很困惑，因为我现在不知道作为一名开发人员该如何行事。

\n

我应该只使用 PnP Core SDK 吗？仅当我需要站点配置引擎时才使用 PnP 框架吗？

\n

或者我可以使用 PnP 框架来执行“创建站点”、“更新列表项”等典型操作吗？

\n

该文章指出了两个库之间的以下差异：

\n

\n

您可能想知道 PnP Framework 和 PnP Core SDK 之间有什么区别。PnP Core SDK 由 PnP 框架使用，并且以独立于 SharePoint 的 CSOM 的思维方式实现。SPO 中引入的越来越多的新功能不一定可以通过 CSOM 获得；这是 Microsoft 365 PnP 引入新 SDK 的动力，该 SDK 包含在 PnP Framework 和 PnP PowerShell 的某些功能之下。

\n

\n

是的 - 但为什么我仍然需要 Pnp 框架？这仅解释了 PnP SDK 是什么...

\n

后来他继续说道：

\n

\n

读完本文后，您可能会问自己：\xe2\x80\x9c我应该使用什么\n以及何时使用？\xe2\x80\x9d

\n

如果您是一名 SharePoint 开发人员，习惯于使用 CSOM，或者如果\n您已经有一个基于 PnP Sites Core\n和 CSOM 构建的现有项目，则您应该依赖 PnP 框架并开始利用丰富的解决方案构建现代解决方案。新的 PnP 框架库提供\n的扩展和实用程序。

\n

如果您是一名 .NET 开发人员，愿意为 SPO 创建新的现代解决方案，请开始使用 PnP Core SDK 并享受使用具有高级抽象层的 Microsoft Graph 和 SPO REST API。

\n

\n

我是一名 SharePoint 开发人员，也是一名 .NET 5 开发人员。但这仍然没有回答我的问题。

\n

我什么时候应该使用 PnP 框架？什么时候出SDK？

\n

对于正常的站点、团队、列表、项目操作等，我可以使用 SDK，对于配置引擎，可以使用框架吗？
\n但是这是正确的吗？

\n

Answer 1

我应该只使用 PnP Core SDK 吗？仅当我需要站点配置引擎时才使用 PnP 框架吗？或者我可以使用 PnP 框架来执行“创建站点”、“更新列表项”等典型操作吗？

您可能只使用 PnP Core SDK，当然，这取决于您的需求，但对于缺少的部分，您仍然可以使用 PnP Core SDK，因为它们使您可以通过 PnP 使用 REST API 来处理这些部分核。

我一直在我们的产品和 SharePoint 之间的多次集成中使用 PnP Core SDK。我们已将其用于创建站点、文件夹、文件夹访问管理组/用户、更新和创建列表项等。

正如他们在这里提到的，他们正在努力进行过渡，这意味着 PnP Core 将成为未来唯一的 SDK，并且他们正在将所有内容都集中在其中。

该库是 PnP 框架的长期演变，我们将实现从 PnP 框架到 PnP Core SDK 的分阶段过渡，而不影响 PnP 框架用户。

不幸的是，我没有有关“配置引擎”状态的任何信息，但正如他们（再次）在这里提到的那样，过渡也将为此完成。

由于这种转变需要相当多的时间和精力，我们计划逐步将内容从 PnP 框架转移到 PnP Core SDK。展望未来，PnP 框架功能将分阶段转移到 PnP Core SDK。

在我一直使用 PnP Core SDK 的那些项目中，我真的很惊讶，因为它已经提供了大量的功能，这使得它非常强大。它是一个巨大的 SDK，并且使用它的人们做得非常出色（尽管文档需要做更多工作，但它仍然比市场上的许多其他产品更好）。

我希望这能为您澄清一些事情。