SharePoint和存储库

这是一个SharePoint+存储库设计问题。就我所知，SharePoint对于适当的存储库方法来说不是一个非常适合的环境。但是有一个模式指南包含一个存储库实现。该代码库基本上以SPWeb作为输入参数，并执行查询/更新等操作

我的问题就在那里：它是一个存储库这一事实意味着不能传递SPWeb，而是从那里获取SPWeb—SPContext.Current.Web将提供该信息以便在存储库中使用。SPWeb作为输入的事实意味着UI层/服务层必须将SPWeb传递给某种方法，这种方法对我来说并不吸引，因为这似乎违反了存储库持久性原则

请给我一些建议

---

干杯

只是一个想法，但您可以始终在存储库层中实例化自己的spsite/spweb对象，将站点/web url用作连接字符串，将spsite/spweb对象用作连接对象。这样，如果您需要从没有当前spcontext的应用程序重新使用代码，则可以在web请求之外使用存储库类

---

与当前spcontext对象相比，创建自己的spsite/spweb对象可能会有轻微的性能问题，但不确定有多少性能问题。

spweb对象包含上下文和权限信息以及网站的详细信息。将其作为参数使使用提升对象而不是用户上下文对象等操作变得容易。您可以像使用连接字符串一样使用站点URL，但这将需要大量的工作，而且调用者几乎总是有一个合适的SPWeb对象可用

---

虽然您正确地认为，理想情况下，您的代码应该独立于所使用的数据存储区，但SharePoint并不是真正为您可以使用标准.net/sql系统构建的那种干净、模块化的代码而设置的。有时您可以接近，但在这种情况下，这并不值得付出努力-调用代码无论如何都依赖于SharePoint，而且项目不太可能移动到列表以外的任何位置。

谢谢David的回答，这正是我想知道的。撇开性能问题不谈，我很困惑地发现这不是模式和实践指南的一部分。让我给您一个示例代码片段Add（T Entity，SPWeb）。这是在ListItemRepository（它类似于所有其他域对象的公共存储库，可在内部用于在SharePoint上执行CRUD操作）。如果您创建自己的spsite/spweb对象，请确保正确处理它们，通常的做法是使用statementsDavid包装它们，可能解释不正确。“这样，如果您需要重新使用不具有当前spcontext的应用程序中的代码，则可以在web请求之外使用存储库类。”这是您的评论，我的问题是模式与实践指南没有在外部生成SPWeb，而是将其作为输入。我在问为什么——这是SharePoint特有的限制吗。