SharePoint and Repositories

This is a SharePoint + repository Design question. As far as my little knowledge goes SharePoint is not a very congenial atmosphere for a proper repository approach. But there is a Patterns guidance that has a repository implementation. That code base basically takes a SPWeb as an input parameter and does the querying / update etc.

My query is there: The fact that it is a repository me开发者_开发知识库ans that SPWeb must NOT be passed but rather taken from there - SPContext.Current.Web would have given that to be used within the repository. The fact SPWeb is taken as an input means that UI layer / Service layer have to pass SPWeb in to the method which somehow is not appealing for me as that looks like violating repository persistence ignorance principles.

Some advice pls

Cheers

The SPWeb object contains context and permission information as well as the details of the site. Having it as a parameter makes it easy to do things like use an elevated object instead of the user context object. You could use a site URL like a connection string, but that would be significantly more work and the caller pretty much always has a suitable SPWeb object available.

While you are correct that your code should ideally be independent of the data store used, SharePoint isn't really set up for the sort of clean, modular code you can build with a standard .net/sql system. You can come close sometimes, but in this case it isn't really worth the effort - the calling code is dependent on SharePoint anyway, and the items are unlikely to be moved to anywhere other than lists.

just a thought, but you could always instantiate your own spsite/spweb objects in your repository layer, using the site/web url like a connection string, and the spsite/spweb objects as connection objects. This way, the repository classes could be used outside of a web request if you ever needed to re-use the code from an app that does not have a current spcontext.

There may be a slight performance issue with creating your own spsite/spweb objects vs the current spcontext objects, but not sure how much.