挂钩到SharePoint服务器端

Question

请注意我说的是将我的代码注入SharePoint服务器端（通过包/加载项等），而不是使用Microsoft.SharePoint.dll或Web服务来访问SharePoint。

所以我的问题是这个，我需要自定义文档库的工作方式，包括自定义权限管理。我一直在浏览Microsoft.SharePoint.dll分析其工作的内部情况。以下是我的观察：

1. SPDocumentLibrary提供了管理文档库的核心逻辑。但是，它本身不是WebPart。
2. 文档库的实际Web部件呈现可能由ListViewWebPart或派生类处理。
3. 实际上是一个SPPictureLibrary类，这使我可以假设可以继承SPDocumentLibrary类来为文档库提供自定义行为。
4. WebPartAdder.SiteWebPartGalleryProvider以某种方式将SPDocumentLibrary与WebPart Microsoft.SharePoint.WebPartPages.WebPartAdder.AddSources方法联系起来。

现在所有这些都是客户端，这一切都不会发生在SharePoint服务器本身（afaik）上。但是，我在SPSecurableObject / SPDocumentLibrary覆盖的SPList上看到了可覆盖的方法，具体为：

1. CheckPermissions
2. GetUserEffectivePermissionInfo
3. GetUserEffectivePermissions
4. EffectiveBasePermissions等

我真正想要做的是能够覆盖SharePoint服务器内CheckPermissions的{​​{1}} / EffectiveBasePermissions以注入我的自定义逻辑。

我现在将我的研究转移到SharePoint服务器端dll并理解它们。但我希望得到一些关于这是否可行/指向正确方向的专家意见。 Microsoft的标志（特别是考虑ASP.NET 2.0 / ASP.NET MVC作为基准）是可扩展性/提供者框架。他们为“事物”提供了出色的供应商。开箱即用，但您可以通过继承/实现某些内容来替换默认提供程序来创建类。所以：

1. 我可以注入SharePoint服务器端吗？我理想的解决方案是创建一个SPDocumentLibrary派生类（服务器端），并将其注入，以便在实例化文档库时，创建我的类对象（而不是SPDocumentLibrary，假设＆ ＃39;也是类服务器端。我仍然需要＆＃34;反映＆＃34; SharePoint服务器端类。）
2. 如果1）是nopes，我是否可以创建自定义SPDocumentLibrary以使用SharePoint文档库，使其具有原生文档库的感觉，但仍允许我使用WebPart访问该Web部件时的派生类（请再次注意，我的所有讨论都围绕SharePoint服务器端，即我的代码在SharePoint的地址空间/ w3wp进程中执行）。
3. 为什么我们在SPDocumentLibrary中都有逻辑。我的意思是它应该是CSOM，它应该只负责序列化/反序列化由/发送到服务器的内容。但是，我看到这个被覆盖的属性中的精细逻辑围绕着权限推断。
4. 如果1）和2）都是no-op（字面意思:)），那么在SharePoint根据这些权限采取任何操作之前，在SharePoint的地址空间中操作时，是否有任何选项可以操纵SharePoint有效权限。

我知道这是一个很长的问题，但希望我能很好地完成我的研究。

Answer 1

我认为您在SharePoint中没有那种控制级别。

不确定您是否查看过SharePoint Events选项。您可以将逻辑添加为SharePoint事件，而不是创建自己的类来添加逻辑。您可以订阅相关事件并相应地添加逻辑。例如，您可以根据自定义逻辑取消更新。但是，我认为您不能自定义基本权限逻辑。

SPList有一个方法'CheckPermissions'，后者又调用基类的'CheckPermissions'（SPSecurableObject）。但是，我怀疑是否可以创建自己的子类，覆盖相关方法并接管权限逻辑。它是SharePoint非常核心的东西，我认为它不是为了自定义。