SharePoint 2019 应用程序的后端

Backend for SharePoint 2019 Application

我们正在为 SharePoint ONPrem 2019 应用程序开发几个基于 SPFx 的表单。

其后端的理想方法是什么?

Extend REST API for SharePoint OR Make .net Core 3.1 WebAPI and expose as custom service

有什么建议吗?

“这取决于”可能是对此的正确答案。选择在 SharePoint Server 中托管的服务有一定的好处,但也有很多缺点。什么更合适或更容易在很大程度上取决于您期望后端有多少复杂性。

在 SharePoint Server 中托管

这意味着您正在公开 Web 服务,例如在 HTTP-based WCF 服务上使用 ISAPI。这有一个很好的好处,即您 运行 SharePoint 中,因此您拥有身份验证 built-in 并且您能够使用 server-side SharePoint API( SSOM) 直接。

不利的一面是,像这样托管您的服务也意味着您现在部署的 SharePoint 场解决方案会带来所有这意味着的问题(例如,部署更加复杂,开发过程通常会变慢,您遇到的任何 GAC 问题可以想到)。当您在 SharePoint 中时,集成外部事物也会变​​得更加复杂。

外部托管

如果您在外部托管 Web 服务,则您可以自由选择所需的任何技术,而不受 SharePoint 自身工作方式的限制。这也让开发和部署变得更好,因为您可以选择任何现代框架来处理这个问题。并且外部事物的集成也变得容易得多。

不利的一面是,您必须处理身份验证,这可能会带来自己的问题。如果您需要与 SharePoint 进行实际通信,那么您将被限制为 client-side 访问权限,例如CSOM.

说到 CSOM,您必须记住,本地没有对 CSOM for SharePoint 的 .NET Core 支持。 Microsoft 明确表示没有相关工作,因此如果您想使用 CSOM,您将被有效地锁定在 .NET Framework 中。不幸的是,这也意味着您不能使用闪亮的 ASP.NET Core 3.1 应用程序,因为它只能在 .NET Core 上运行。如果您想使用 ASP.NET Core,则必须坚持使用 2.1(这是仍在 .NET Framework 上运行的最后一个受支持的版本),或者拆分 ASP.NET Core 应用程序不支持的体系结构' 直接与 SharePoint 对话,但将其工作转发给其他一些 (.NET Framework) 服务,然后进行通信。


所以最后,这取决于你想做什么,以及你能忍受什么样的问题。

随着时间的推移,如果您的后端仅依赖于 SP 列表和其他依赖项,我们发现最好的解决方案是使用 .Net FX 完整版。

否则,如果你后端使用SQL服务器,那么最好使用最新的.net core。这也是因为,一些次要的 SP 列表操作您也可以直接从前端使用 JSOM 轻松完成,而无需 CSOM。